[erlang-questions] bug in ssl?

Ingela Andin ingela@REDACTED
Wed Jun 1 18:48:55 CEST 2011


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 <vinodhg@REDACTED>:
>> 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 <ingela.andin@REDACTED> 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 <vinodhg@REDACTED>:
>>> > 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
>>> > erlang-questions@REDACTED
>>> > http://erlang.org/mailman/listinfo/erlang-questions
>>> >
>>> >
>>
>>
>>
>> --
>>
>> Thanks & Regards,
>> Vinod H. G.
>>
>



More information about the erlang-questions mailing list