[erlang-bugs] file:sendfile/5 bug and possible DOS attack

[Lukas Larsson]

I've now implemented the fix I proposed for this. You can view the fix 
here: 
https://github.com/garazdawi/otp/tree/lukas/erts/sendfile_no_async_pool. 
If the tests pass I will merge it asap.

Lukas

On 22/10/13 09:25, Lukas Larsson wrote:
> Hello Christopher,
>
> The reason behind favoring the async threads is that non-blocking 
> sendfile calls on some OSs sometimes behave incorrectly. Unfortunately 
> at the moment I cannot remember which OS it was, but it is none of the 
> majorly used ones.
>
> It is of course not good that this feature opens up the VM for that 
> kind of attack.
>
> My suggestion of a fix would be to add an option to sendfile/5 that 
> specifies whether async threads should be used or not, and default 
> this to false. This leaves the choice up to the user of sendfile/5 and 
> defaults to be safe from attacks.
>
> Thanks for reporting this quite serious flaw in the sendfile 
> implementation!
>
> Lukas
>
> On 21/10/13 15:02, Christopher Faulet wrote:
>> Hi,
>>
>> This summer, at my company, we encountered a problem that leads to the
>> VM hanging. After some painful investigation, we found that the problem
>> came from thefile:sendfile/5  function.
>>
>> When async threads are enabled, during a call tofile:sendfile/5  the
>> efile driver sets the TCP socket in blocking mode. So an unresponsive
>> client can block the sendfile() syscall, thus blocking an async thread.
>> With few unresponsive clients, all async threads can be blocked and the
>> VM hangs (no more I/O are possible).
>>
>> I attached 2 escripts to reproduce the bug:
>>
>> * server - listen on a socket and wait a client connection to send a
>> large file using gen_tcp:send orfile:sendfile:
>>
>>    $> ./server 1234 /path/to/bigfile send
>> or
>>    $> ./server 1234 /path/to/bigfile sendfile
>>
>> * slow_client - open a connection on the server and read incoming data
>> with a sleep of 10 seconds between each read:
>>
>>    $> ./slow_client 127.0.0.1 1234
>>
>> The server is started with 1 async thread. Every 2 seconds the server
>> tries to read the file info. When "sendfile" method is used, the call to
>> file:read_file_info/1  is blocked; all I/O are blocked, the VM is out.
>> When async threads are disabled or when the "send" method is used, there
>> is no problem. The file is sent (slowly) and the VM is still responsive.
>>
>> So it is very easy to do a DOS attack on systems that use
>> file:sendfile/5  with async threads enabled. The problem comes from a
>> design choice of the efile driver. I have no solution to propose, but it
>> could be a good idea to add a warning in the documentation of
>> file:sendfile/5  (especially that the documentation encourages the use of
>> async threads).
>>
>> Regards,
>>
>>
>> _______________________________________________
>> erlang-bugs mailing list
>> erlang-bugs@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-bugs
>
>
>
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20140127/2fc3bed7/attachment.htm>