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

Lukas Larsson <>
Tue Oct 22 09:25:27 CEST 2013


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 the file:sendfile/5 function.
>
> When async threads are enabled, during a call to file: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 or file: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
> 
> http://erlang.org/mailman/listinfo/erlang-bugs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20131022/ef92ed1b/attachment.html>


More information about the erlang-bugs mailing list