|
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 _______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions |
|
Hi!
Will the following patch make the problem go away? diff --git a/lib/ssl/src/ssl_record.erl b/lib/ssl/src/ssl_record.erl index f1c0073..ed57166 100644 --- a/lib/ssl/src/ssl_record.erl +++ b/lib/ssl/src/ssl_record.erl @@ -62,6 +62,8 @@ -compile(inline). +-define(INITIAL_BYTES, 5). + %%==================================================================== %% Internal application API %%==================================================================== @@ -368,8 +370,12 @@ get_tls_records_aux(<<1:1, Length0:15, _/binary>>,_Acc) ?ALERT_REC(?FATAL, ?RECORD_OVERFLOW); get_tls_records_aux(Data, Acc) -> - {lists:reverse(Acc), Data}. - + case size(Data) =< ?MAX_CIPHER_TEXT_LENGTH + ?INITIAL_BYTES of + true -> + {lists:reverse(Acc), Data}; + false -> + ?ALERT_REC(?FATAL, ?UNEXPECTED_MESSAGE) + end. %%-------------------------------------------------------------------- -spec protocol_version(tls_atom_version() | tls_version()) -> tls_version() | tls_atom_version(). Regards Ingela Erlang/OTP team - Ericsson AB 2011/6/1 vinod hg <[hidden email]>: > 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 > > _______________________________________________ > erlang-questions mailing list > [hidden email] > http://erlang.org/mailman/listinfo/erlang-questions > > erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions |
|
Thanks Ingela. I tried with your patch and it is working fine. Will run it whole day and let you know. Will this be part of official release?
On Wed, Jun 1, 2011 at 2:05 PM, Ingela Andin <[hidden email]> wrote: Hi! -- Vinod H. G. _______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions |
|
Hi!
Well alas it just missed the R14B03 release, but it will of course be part of the next release. It will also be on github next week. Regards Ingela Erlang/OTP team - Ericsson AB > 2011/6/1 vinod hg <[hidden email]>: >> Thanks Ingela. I tried with your patch and it is working fine. Will run it >> whole day and let you know. Will this be part of official release? >> >> On Wed, Jun 1, 2011 at 2:05 PM, Ingela Andin <[hidden email]> wrote: >>> >>> Hi! >>> >>> Will the following patch make the problem go away? >>> >>> diff --git a/lib/ssl/src/ssl_record.erl b/lib/ssl/src/ssl_record.erl >>> index f1c0073..ed57166 100644 >>> --- a/lib/ssl/src/ssl_record.erl >>> +++ b/lib/ssl/src/ssl_record.erl >>> @@ -62,6 +62,8 @@ >>> >>> -compile(inline). >>> >>> +-define(INITIAL_BYTES, 5). >>> + >>> %%==================================================================== >>> %% Internal application API >>> %%==================================================================== >>> @@ -368,8 +370,12 @@ get_tls_records_aux(<<1:1, Length0:15, >>> _/binary>>,_Acc) >>> ?ALERT_REC(?FATAL, ?RECORD_OVERFLOW); >>> >>> get_tls_records_aux(Data, Acc) -> >>> - {lists:reverse(Acc), Data}. >>> - >>> + case size(Data) =< ?MAX_CIPHER_TEXT_LENGTH + ?INITIAL_BYTES of >>> + true -> >>> + {lists:reverse(Acc), Data}; >>> + false -> >>> + ?ALERT_REC(?FATAL, ?UNEXPECTED_MESSAGE) >>> + end. >>> %%-------------------------------------------------------------------- >>> -spec protocol_version(tls_atom_version() | tls_version()) -> >>> tls_version() | tls_atom_version(). >>> >>> >>> Regards Ingela Erlang/OTP team - Ericsson AB >>> >>> >>> 2011/6/1 vinod hg <[hidden email]>: >>> > 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 >>> > >>> > _______________________________________________ >>> > erlang-questions mailing list >>> > [hidden email] >>> > http://erlang.org/mailman/listinfo/erlang-questions >>> > >>> > >> >> >> >> -- >> >> Thanks & Regards, >> Vinod H. G. >> > erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions |
| Powered by Nabble | Edit this page |
