[erlang-questions] bug in ssl?

[Ingela Andin]

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.
>>
>