[asterisk-bugs] [JIRA] (ASTERISK-24333) Crash in DTLS
Matt Jordan (JIRA)
noreply at issues.asterisk.org
Thu Sep 25 11:27:29 CDT 2014
[ https://issues.asterisk.org/jira/browse/ASTERISK-24333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=222783#comment-222783 ]
Matt Jordan edited comment on ASTERISK-24333 at 9/25/14 11:26 AM:
------------------------------------------------------------------
So, there's a whole mess of uninitialized values getting used by {{libssl}}. There's not much we can do about that.
However, valgrind did complain about an invalid read (off by one) when reading from the master key buffer allocated in {{res_srtp}}:
{noformat}
==23717== Thread 88:
==23717== Invalid read of size 1
==23717== at 0xA794F00: v128_copy_octet_string (in /usr/lib64/libsrtp.so.0.0.0)
==23717== by 0xA792898: aes_icm_context_init (in /usr/lib64/libsrtp.so.0.0.0)
==23717== by 0xA78CFFC: srtp_kdf_init (in /usr/lib64/libsrtp.so.0.0.0)
==23717== by 0xA78D089: srtp_stream_init_keys (in /usr/lib64/libsrtp.so.0.0.0)
==23717== by 0xA78D59E: srtp_stream_init (in /usr/lib64/libsrtp.so.0.0.0)
==23717== by 0xA78ED8C: srtp_add_stream (in /usr/lib64/libsrtp.so.0.0.0)
==23717== by 0xA78EE93: srtp_create (in /usr/lib64/libsrtp.so.0.0.0)
==23717== by 0xA5853A8: ast_srtp_create (res_srtp.c:450)
==23717== by 0x558421: ast_rtp_instance_add_srtp_policy (rtp_engine.c:2072)
==23717== by 0xF566BA7: dtls_srtp_setup (res_rtp_asterisk.c:1661)
==23717== by 0xF566FEC: __rtp_recvfrom (res_rtp_asterisk.c:1739)
==23717== by 0xF5672A9: rtp_recvfrom (res_rtp_asterisk.c:1789)
==23717== Address 0x29b20f2e is 0 bytes after a block of size 30 alloc'd
==23717== at 0x4A0577B: calloc (vg_replace_malloc.c:593)
==23717== by 0x596BC8: _ast_calloc (utils.h:514)
==23717== by 0xA584B04: ast_srtp_policy_set_master_key (res_srtp.c:293)
==23717== by 0xF566ABD: dtls_srtp_setup (res_rtp_asterisk.c:1649)
==23717== by 0xF566FEC: __rtp_recvfrom (res_rtp_asterisk.c:1739)
==23717== by 0xF5672A9: rtp_recvfrom (res_rtp_asterisk.c:1789)
==23717== by 0xF5706B2: ast_rtp_read (res_rtp_asterisk.c:3862)
==23717== by 0x551286: ast_rtp_instance_read (rtp_engine.c:314)
==23717== by 0xC43C641: sip_rtp_read (chan_sip.c:8194)
==23717== by 0xC43CDF0: sip_read (chan_sip.c:8291)
==23717== by 0x47C91C: __ast_read (channel.c:4054)
==23717== by 0x47E6C5: ast_read (channel.c:4408)
{noformat}
That's a little odd, since the length of the {{unsigned char}} buffer passed to that function shouldn't be NULL terminated or have any other requirements that necessitate an additional byte of space. This may actually be a bug in {{libsrtp}} - see [http://sourceforge.net/p/srtp/bugs/7/]. It certainly appears like {{aes_icm_context_init}} is reading past the key. There's a few other bug reports from browser vendors regarding this same function; they may be related.
I've attached something that _may_ fix this - it simply allocates one additional byte of space in {{res_srtp}}. That should be harmless for SDES-SRTP or DTLS, as the actual key length would be unaffected.
As this does appear to be a bug in {{libsrtp}}, if this doesn't work around the issue, you may have to push the issue to that project.
was (Author: mjordan):
So, there's a whole mess of uninitialized values getting used by {{libssl}}. There's not much we can do about that.
However, valgrind did complain about an invalid read (off by one) when reading from the master key buffer allocated in {{res_srtp}}:
{noformat}
==23717== Thread 88:
==23717== Invalid read of size 1
==23717== at 0xA794F00: v128_copy_octet_string (in /usr/lib64/libsrtp.so.0.0.0)
==23717== by 0xA792898: aes_icm_context_init (in /usr/lib64/libsrtp.so.0.0.0)
==23717== by 0xA78CFFC: srtp_kdf_init (in /usr/lib64/libsrtp.so.0.0.0)
==23717== by 0xA78D089: srtp_stream_init_keys (in /usr/lib64/libsrtp.so.0.0.0)
==23717== by 0xA78D59E: srtp_stream_init (in /usr/lib64/libsrtp.so.0.0.0)
==23717== by 0xA78ED8C: srtp_add_stream (in /usr/lib64/libsrtp.so.0.0.0)
==23717== by 0xA78EE93: srtp_create (in /usr/lib64/libsrtp.so.0.0.0)
==23717== by 0xA5853A8: ast_srtp_create (res_srtp.c:450)
==23717== by 0x558421: ast_rtp_instance_add_srtp_policy (rtp_engine.c:2072)
==23717== by 0xF566BA7: dtls_srtp_setup (res_rtp_asterisk.c:1661)
==23717== by 0xF566FEC: __rtp_recvfrom (res_rtp_asterisk.c:1739)
==23717== by 0xF5672A9: rtp_recvfrom (res_rtp_asterisk.c:1789)
==23717== Address 0x29b20f2e is 0 bytes after a block of size 30 alloc'd
==23717== at 0x4A0577B: calloc (vg_replace_malloc.c:593)
==23717== by 0x596BC8: _ast_calloc (utils.h:514)
==23717== by 0xA584B04: ast_srtp_policy_set_master_key (res_srtp.c:293)
==23717== by 0xF566ABD: dtls_srtp_setup (res_rtp_asterisk.c:1649)
==23717== by 0xF566FEC: __rtp_recvfrom (res_rtp_asterisk.c:1739)
==23717== by 0xF5672A9: rtp_recvfrom (res_rtp_asterisk.c:1789)
==23717== by 0xF5706B2: ast_rtp_read (res_rtp_asterisk.c:3862)
==23717== by 0x551286: ast_rtp_instance_read (rtp_engine.c:314)
==23717== by 0xC43C641: sip_rtp_read (chan_sip.c:8194)
==23717== by 0xC43CDF0: sip_read (chan_sip.c:8291)
==23717== by 0x47C91C: __ast_read (channel.c:4054)
==23717== by 0x47E6C5: ast_read (channel.c:4408)
{noformat}
That's a little odd, since the length of the {{unsigned char}} buffer passed to that function shouldn't be NULL terminated or have any other requirements that necessitate an additional byte of space. This may actually be a bug in {{libsrtp}} - see [http://sourceforge.net/p/srtp/bugs/7/]. It certainly appears like {{aes_icm_context_init }} is reading past the key. There's a few other bug reports from browser vendors regarding this same function; they may be related.
I've attached something that _may_ fix this - it simply allocates one additional byte of space in {{res_srtp}}. That should be harmless for SDES-SRTP or DTLS, as the actual key length would be unaffected.
As this does appear to be a bug in {{libsrtp}}, if this doesn't work around the issue, you may have to push the issue to that project.
> Crash in DTLS
> -------------
>
> Key: ASTERISK-24333
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-24333
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Channels/chan_sip/WebSocket
> Affects Versions: 11.12.0
> Reporter: Badalian Vyacheslav
> Assignee: Matt Jordan
> Severity: Critical
> Attachments: valgrind2.txt, valgrind.txt
>
>
> Asterisk. DTLS. Only WSS. 300+ Clients
> CentOS 6. All last updates
> m1-asterisk01*CLI> *** glibc detected *** /usr/sbin/asterisk: double free or corruption (!prev): 0x00007f95f40854a0 ***
> ======= Backtrace: =========
> /lib64/libc.so.6(+0x75e76)[0x7f968725fe76]
> /lib64/libc.so.6(+0x789b3)[0x7f96872629b3]
> /usr/lib64/libcrypto.so.10(CRYPTO_realloc_clean+0xf3)[0x7f968662fde3]
> /usr/lib64/libcrypto.so.10(BUF_MEM_grow_clean+0x86)[0x7f968669f996]
> /usr/lib64/libcrypto.so.10(+0xda3f3)[0x7f96866a13f3]
> /usr/lib64/libcrypto.so.10(BIO_write+0x77)[0x7f96866a05f7]
> /usr/lib64/libcrypto.so.10(+0xdc621)[0x7f96866a3621]
> /usr/lib64/libssl.so.10(dtls1_do_write+0x18d)[0x7f96869e58ad]
> /usr/lib64/libssl.so.10(dtls1_accept+0xaa7)[0x7f96869dfc77]
> /usr/lib/asterisk/modules/res_rtp_asterisk.so(+0xf6d5)[0x7f964048c6d5]
> /usr/lib/asterisk/modules/res_rtp_asterisk.so(+0xf7a6)[0x7f964048c7a6]
> /usr/lib/asterisk/modules/res_rtp_asterisk.so(+0x199d1)[0x7f96404969d1]
> /usr/lib/asterisk/modules/res_rtp_asterisk.so(+0x48792)[0x7f96404c5792]
> /usr/lib/asterisk/modules/res_rtp_asterisk.so(+0xad46)[0x7f9640487d46]
> /usr/lib/asterisk/modules/res_rtp_asterisk.so(+0x39cbf)[0x7f96404b6cbf]
> /lib64/libpthread.so.0(+0x79d1)[0x7f96861ad9d1]
> /lib64/libc.so.6(clone+0x6d)[0x7f96872d286d]
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list