[openssl-dev] [openssl.org #3592] bug report. Crash. Critical? Security bug?

Вячеслав Бадалян via RT rt at openssl.org
Thu Dec 25 11:24:50 UTC 2014


i found that Asterisk do corruption in SSL. I will fix it and replay to you

2014-12-25 5:58 GMT+03:00 Вячеслав Бадалян <v.badalyan at open-bs.ru>:

> New place crash
>
> (gdb) bt
>
> #0  0x00000037c9e32625 in raise (sig=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
>
> #1  0x00000037c9e33e05 in abort () at abort.c:92
>
> #2  0x0000003dbac69e3f in OpenSSLDie (file=<value optimized out>,
> line=<value optimized out>, assertion=<value optimized out>) at
> cryptlib.c:923
>
> #3  0x0000003dbb03c220 in do_dtls1_write (s=0x7fff34010940, type=22,
> buf=0x7fff1c0ac007 "\v", len=243, create_empty_fragment=0) at d1_pkt.c:1484
>
> #4  0x0000003dbb03faf1 in dtls1_do_write (s=0x7fff34010940, type=22) at
> d1_both.c:378
>
> #5  0x0000003dbb038e07 in dtls1_accept (s=0x7fff34010940) at d1_srvr.c:426
>
> #6  0x0000003dbb03d8ad in dtls1_read_bytes (s=0x7fff34010940, type=23,
> buf=0x7fff34059488 "\026\376\377", len=121, peek=0) at d1_pkt.c:787
>
> #7  0x0000003dbb027ed0 in ssl3_read_internal (s=0x7fff34010940,
> buf=0x7fff34059488, len=121, peek=0) at s3_lib.c:4273
>
> #8  0x00007fff9e952ef5 in __rtp_recvfrom (instance=0x7fff3405f288,
> buf=0x7fff34059488, size=8192, flags=0, sa=0x7fff9aa1e370, rtcp=0) at
> res_rtp_asterisk.c:2019
>
> #9  0x00007fff9e95331f in rtp_recvfrom (instance=0x7fff3405f288,
> buf=0x7fff34059488, size=8192, flags=0, sa=0x7fff9aa1e370) at
> res_rtp_asterisk.c:2094
>
> #10 0x00007fff9e95c621 in ast_rtp_read (instance=0x7fff3405f288, rtcp=0)
> at res_rtp_asterisk.c:4127
>
> #11 0x0000000000551bcf in ast_rtp_instance_read (instance=0x7fff3405f288,
> rtcp=0) at rtp_engine.c:314
>
> #12 0x00007fffb2ae07cd in sip_rtp_read (ast=0x7fff340ab648,
> p=0x7fff3402f588, faxdetect=0x7fff9aa1e604) at chan_sip.c:8192
>
> #13 0x00007fffb2ae0f7c in sip_read (ast=0x7fff340ab648) at chan_sip.c:8289
>
> #14 0x000000000047cb05 in __ast_read (chan=0x7fff340ab648, dropaudio=0) at
> channel.c:4054
>
> #15 0x000000000047e8ae in ast_read (chan=0x7fff340ab648) at channel.c:4408
>
> #16 0x00007fffa716ba1a in wait_for_answer (in=0x7fff340ab648,
> out_chans=0x7fff9aa20970, to=0x7fff9aa2096c, peerflags=0x7fff9aa20ec0,
> opt_args=0x7fff9aa201b0, pa=0x7fff9aa20290, num_in=0x7fff9aa20950,
> result=0x7fff9aa2028c,
>
>     dtmf_progress=0x0, ignore_cc=1, forced_clid=0x7fff9aa20060,
> stored_clid=0x7fff9aa20010) at app_dial.c:1562
>
> #17 0x00007fffa7170f70 in dial_exec_full (chan=0x7fff340ab648,
> data=0x7fff9aa23120 "SIP/sbc/79139601839,300,Tt", peerflags=0x7fff9aa20ec0,
> continue_exec=0x0) at app_dial.c:2683
>
> #18 0x00007fffa7173789 in dial_exec (chan=0x7fff340ab648,
> data=0x7fff9aa23120 "SIP/sbc/79139601839,300,Tt") at app_dial.c:3130
>
> #19 0x000000000052b7dd in pbx_exec (c=0x7fff340ab648, app=0x106f200,
> data=0x7fff9aa23120 "SIP/sbc/79139601839,300,Tt") at pbx.c:1622
>
> #20 0x0000000000536284 in pbx_extension_helper (c=0x7fff340ab648, con=0x0,
> context=0x7fff340ac498 "macro-dialout-trunk", exten=0x7fff340ac4e8 "s",
> priority=22, label=0x0, callerid=0x7fff1c05dc70 "74996051913",
> action=E_SPAWN,
>
>     found=0x7fff9aa2578c, combined_find_spawn=1) at pbx.c:4915
>
> #21 0x000000000053971f in ast_spawn_extension (c=0x7fff340ab648,
> context=0x7fff340ac498 "macro-dialout-trunk", exten=0x7fff340ac4e8 "s",
> priority=22, callerid=0x7fff1c05dc70 "74996051913", found=0x7fff9aa2578c,
> combined_find_spawn=1)
>
>     at pbx.c:6037
>
> #22 0x00007fffab3f20b0 in _macro_exec (chan=0x7fff340ab648,
> data=0x7fff9aa28490 "dialout-trunk,4,79139601839,,off", exclusive=0) at
> app_macro.c:412
>
> #23 0x00007fffab3f3342 in macro_exec (chan=0x7fff340ab648,
> data=0x7fff9aa28490 "dialout-trunk,4,79139601839,,off") at app_macro.c:585
>
> #24 0x000000000052b7dd in pbx_exec (c=0x7fff340ab648, app=0xfbc430,
> data=0x7fff9aa28490 "dialout-trunk,4,79139601839,,off") at pbx.c:1622
>
> #25 0x0000000000536284 in pbx_extension_helper (c=0x7fff340ab648, con=0x0,
> context=0x7fff340ac498 "macro-dialout-trunk", exten=0x7fff340ac4e8 "s",
> priority=5, label=0x0, callerid=0x7fff1c05dc70 "74996051913",
> action=E_SPAWN,
>
>     found=0x7fff9aa2ab70, combined_find_spawn=1) at pbx.c:4915
>
> #26 0x000000000053971f in ast_spawn_extension (c=0x7fff340ab648,
> context=0x7fff340ac498 "macro-dialout-trunk", exten=0x7fff340ac4e8 "s",
> priority=5, callerid=0x7fff1c05dc70 "74996051913", found=0x7fff9aa2ab70,
> combined_find_spawn=1)
>
>     at pbx.c:6037
>
> #27 0x000000000053aebc in __ast_pbx_run (c=0x7fff340ab648, args=0x0) at
> pbx.c:6512
>
> #28 0x000000000053c999 in pbx_thread (data=0x7fff340ab648) at pbx.c:6842
>
> #29 0x00000000005990d5 in dummy_start (data=0x7fff34018e00) at utils.c:1223
>
> #30 0x00000037ca2079d1 in start_thread (arg=0x7fff9aa2b700) at
> pthread_create.c:301
>
> #31 0x00000037c9ee89dd in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
>
> 2014-12-23 16:53 GMT+03:00 Вячеслав Бадалян <v.badalyan at open-bs.ru>:
>
>> another crash. Double free.
>>
>>
>>
>>
>> 2014-12-22 17:29 GMT+03:00 Вячеслав Бадалян <v.badalyan at open-bs.ru>:
>>
>>> Hmm... again asserts...
>>> s->init_num == 0
>>>
>>> full backtrace attached...
>>>
>>> 2014-12-18 13:10 GMT+03:00 Matt Caswell via RT <rt at openssl.org>:
>>>
>>>> On Thu Dec 18 04:54:57 2014, v.badalyan at open-bs.ru wrote:
>>>> > Thanks! Great!
>>>> > 6000 calls. No crashes or leaks.... only messages like this in
>>>> > asterisk
>>>> > [2014-12-18 04:59:20] ERROR[31074][C-000013d4] res_rtp_asterisk.c:
>>>> > DTLS
>>>> > failure occurred on RTP instance '0x298c1d68' due to reason 'digest
>>>> > check
>>>> > failed', terminating
>>>> > [2014-12-18 04:59:28] ERROR[31081][C-000013d7] res_rtp_asterisk.c:
>>>> > DTLS
>>>> > failure occurred on RTP instance '0x29d16508' due to reason 'digest
>>>> > check
>>>> > failed', terminating
>>>> > [2014-12-18 05:04:07] ERROR[31881][C-0000142d] res_rtp_asterisk.c:
>>>> > DTLS
>>>> > failure occurred on RTP instance '0x29fe0ac8' due to reason 'digest
>>>> > check
>>>> > failed', terminating
>>>> >
>>>> > But 99% call go normal. We will test on production server and high
>>>> > load.
>>>>
>>>> Good news. Let me know how the testing goes in production so that I can
>>>> (hopefully) close the ticket.
>>>>
>>>> Matt
>>>>
>>>>
>>>
>>>
>>> --
>>> С уважением,
>>> Бадалян Вячеслав Борисович
>>>
>>> ООО "Открытые бизнес-решения"
>>> Технический директор
>>> +7 (495) 666-0-111
>>> http://www.open-bs.ru
>>>
>>
>>
>>
>> --
>> С уважением,
>> Бадалян Вячеслав Борисович
>>
>> ООО "Открытые бизнес-решения"
>> Технический директор
>> +7 (495) 666-0-111
>> http://www.open-bs.ru
>>
>
>
>
> --
> С уважением,
> Бадалян Вячеслав Борисович
>
> ООО "Открытые бизнес-решения"
> Технический директор
> +7 (495) 666-0-111
> http://www.open-bs.ru
>



-- 
С уважением,
Бадалян Вячеслав Борисович

ООО "Открытые бизнес-решения"
Технический директор
+7 (495) 666-0-111
http://www.open-bs.ru



More information about the openssl-dev mailing list