[erlang-questions] bug in ssl?

vinod hg <>
Wed Jun 1 05:23:04 CEST 2011


Hi,



I am using mochiweb as a https web server for my application (Secured socket
layer). I am new to security.

One of the users reported that sending random data to the web server port
makes beam.smp to consume 100% CPU indefinitely for a very long period.



Step to reproduce

1.       Start a mochiweb https server (can use mochiweb web storage app
example provided with no other options) on a specific port (ex: 8443 )

2.       Run the command “nc  [IP address]  8443 <  /dev/urandom”

3.       The server rejects the connection (you may get ssl record error
sometimes). The command returns to the shell

4.       Repeat the above command for some time till the command doesn’t
return back to shell.

5.       Observe beam.smp taking 100% CPU and also  memory getting increase.
(It may reach system limit and crash)

6.       If you stop the command (nc ^C), it returns to normal



Observations

It is reproducible in both Linux and windows.

It happens for other https web server (tried with musultin)

It does not happen for http server (should be in lib ssl).

Tried giving different SSL options like {verify, verify_peer} with empty
certificate as valid, but did not help.

For other web servers written in other language this is not the behavior.
Example lighttpd (php) nc just returns back to shell everytime.





I debugged the issue to find that in other cases where the nc commands
return immediately to shell the ssl connection does not succeed (behaves
normally).

But for the case where nc does not return back, the call is in an infinite
loop “next_tls_record in ssl_connection.erl” , thus making the CPU to take
100% and in memory increase.



This can lead denial of service attack. Is this a bug and should I raise it
in bug report forum.



Any help will be appreciated.



Thanks & Regards,

Vinod
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110601/11c29db5/attachment.html>


More information about the erlang-questions mailing list