Quantcast

bug in ssl?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

bug in ssl?

vinod hg

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: bug in ssl?

Ingela Andin
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: bug in ssl?

vinod hg
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: bug in ssl?

Ingela Andin-2
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
Loading...