[erlang-bugs] file:sendfile/5 bug and possible DOS attack
Mon Jan 27 15:22:14 CET 2014
I've now implemented the fix I proposed for this. You can view the fix
If the tests pass I will merge it asap.
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
> On 21/10/13 15:02, Christopher Faulet wrote:
>> 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
>> $> ./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).
>> erlang-bugs mailing list
> erlang-bugs mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-bugs