[Home]

Summary:ASTERISK-28260: Asterisk segfault when rtp negotiation is wrong or fails
Reporter:Sotiris Ganouris (sotoz)Labels:patch pjsip security
Date Opened:2019-01-24 10:50:18.000-0600Date Closed:2019-02-28 12:22:55.000-0600
Priority:BlockerRegression?
Status:Closed/CompleteComponents:Channels/chan_pjsip
Versions:15.5.0 15.7.1 16.1.1 Frequency of
Occurrence
Related
Issues:
Environment:Linux asterisk-06 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u3 (2018-08-19) x86_64 GNU/LinuxAttachments:( 0) 0001-res_pjsip_sdp_rtp-Fix-return-code-from-apply_negotia.patch
( 1) full.txt
( 2) patch.txt
( 3) test-file-1548335450.g729
( 4) uas_segfault.xml
Description:Hello Asterisk team,

We are observing a segfault in Asterisk when Asterisk receives rtp streams for a codec that does not support (or does not negotiates). We believe that this is a security concern for asterisk and we couldn’t find anything reported so far about this specific issue. We are trying to find ways to patch it as it also affects latest master. If this was reported or fixed already somewhere else please advise us.

Example and steps to reproduce:

1. Originate a call from Asterisk to a provider. Offer codecs alaw/ulaw/amr/amrwb.
2. Provider responds with 180 with sdp body that specifies g729 codec and basically ignores the supported codecs from the initial INVITE from Asterisk.
3. Asterisk throws the following NOTICE.

[2019-01-23 13:49:15] NOTICE[19010]: res_pjsip_sdp_rtp.c:416 set_caps: No joint capabilities for 'audio' media stream between our configuration((alaw|ulaw|amr|amrwb)) and incoming SDP((nothing))

4. Provider starts streaming RTP packets with g729 codec.
5. Asterisk segfaults with
{noformat}
Jan 23 13:49:15 asterisk-06 kernel: [13236574.960262] asterisk[23463]: segfault at 7f62d94ffdc8 ip 000055c951b59585 sp 00007f5a1d6ec378 error 4 in asterisk[55c95194b000+2ee000]
{noformat}
We are able to reproduce this with a SIPP (SIPp v3.6-dev-100-gffdf9be-RTPSTREAM) scenario that acts as a UAS (provider) and uses g729 encoded file for streaming.

sipp -sf uas_segfault.xml -p 5060  -set advertisedip [your ip]
(I couldn't attach the xml here but can send link if needed)

We were able to reproduce it with Asterisk 15.7.1, 15.5.0, 16.1.1. OS is Linux voice-asterisk-06 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u3 (2018-08-19) x86_64 GNU/Linux. Core dumps follows:

Asterisk 15.7.1
{noformat}
(gdb) where
#0  0x0000555dfd26fe85 in ast_stream_topology_get_stream (topology=0x7f7f50021bd8, stream_num=stream_num@entry=4294967295) at stream.c:432
#1  0x0000555dfd13eb66 in __ast_read (chan=chan@entry=0x7f7f2c003050, dropaudio=dropaudio@entry=0, dropnondefault=dropnondefault@entry=1) at channel.c:3703
#2  0x0000555dfd13fa0c in ast_read (chan=chan@entry=0x7f7f2c003050) at channel.c:4193
#3  0x00007f7ef8432951 in echo_exec (chan=0x7f7f2c003050, data=<optimized out>) at app_echo.c:62
#4  0x0000555dfd20e639 in pbx_exec (c=0x7f7f2c003050, app=app@entry=0x555dfe84a300, data=data@entry=0x0) at pbx_app.c:492
#5  0x0000555dfd2054c5 in pbx_outgoing_exec (data=data@entry=0x7f7f2c0019b0) at pbx.c:7593
#6  0x0000555dfd2886e9 in dummy_start (data=<optimized out>) at utils.c:1258
#7  0x00007f7f5ba05494 in start_thread (arg=0x7f7eed8cb700) at pthread_create.c:333
#8  0x00007f7f5a60facf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
{noformat}
Asterisk 15.5.0
{noformat}
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/asterisk -f -C /etc/asterisk/asterisk.conf'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000558d55bd7cc1 in ast_stream_topology_get_stream (topology=0x7f0dd80e0b60, stream_num=4294967295) at stream.c:432
432 return AST_VECTOR_GET(&topology->streams, stream_num);
[Current thread is 1 (Thread 0x7f0d6b0f0700 (LWP 25557))]
(gdb) bt
#0  0x0000558d55bd7cc1 in ast_stream_topology_get_stream (topology=0x7f0dd80e0b60, stream_num=4294967295) at stream.c:432
#1  0x0000558d55a810ba in __ast_read (chan=0x7f0dc0028a58, dropaudio=0, dropnondefault=1) at channel.c:3703
#2  0x0000558d55a82fce in ast_read (chan=0x7f0dc0028a58) at channel.c:4193
#3  0x0000558d55acb38d in monitor_dial (dial=0x7f0dc00913f0, chan=0x0) at dial.c:862
#4  0x0000558d55acb9bd in ast_dial_run (dial=0x7f0dc00913f0, chan=0x0, async=0) at dial.c:979
#5  0x00007f0d3e9fbf8a in ari_originate_dial (data=0x7f0dc00913f0) at ari/resource_channels.c:981
#6  0x0000558d55bf52b2 in dummy_start (data=0x7f0dc01e0e90) at utils.c:1258
#7  0x00007f0de916a494 in start_thread (arg=0x7f0d6b0f0700) at pthread_create.c:333
#8  0x00007f0de83e5acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
{noformat}
Asterisk 16.1.1
{noformat}
(gdb) bt
#0  0x0000562dc0d9b995 in ast_stream_topology_get_stream (topology=0x7f18c001bb58, stream_num=stream_num@entry=4294967295) at stream.c:479
#1  0x0000562dc0cb6206 in __ast_read (chan=chan@entry=0x7f1898001480, dropaudio=dropaudio@entry=0, dropnondefault=dropnondefault@entry=1) at channel.c:3681
#2  0x0000562dc0cb70ac in ast_read (chan=chan@entry=0x7f1898001480) at channel.c:4171
#3  0x00007f1878573951 in echo_exec (chan=0x7f1898001480, data=<optimized out>) at app_echo.c:62
#4  0x0000562dc0d3c6f9 in pbx_exec (c=0x7f1898001480, app=app@entry=0x562dc3ecc680, data=data@entry=0x0) at pbx_app.c:492
#5  0x0000562dc0d33475 in pbx_outgoing_exec (data=data@entry=0x7f1898000e20) at pbx.c:7593
#6  0x0000562dc0db14ec in dummy_start (data=<optimized out>) at utils.c:1249
#7  0x00007f18d3c25494 in start_thread (arg=0x7f1865fa1700) at pthread_create.c:333
#8  0x00007f18d282facf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
{noformat}
Current Master
Asterisk-master(1797cd2071cc740c6ff13e57f8cbda1bbbcf6647)
{noformat}
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
whCore was generated by `asterisk -cvvvvvvvvvvvvvvvvvvv'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000555f1ddd3a95 in ast_stream_topology_get_stream (topology=0x7f845802f9e8, stream_num=stream_num@entry=4294967295) at stream.c:479
479        return AST_VECTOR_GET(&topology->streams, stream_num);
[Current thread is 1 (Thread 0x7f83fd923700 (LWP 8383))]
(gdb) where
#0  0x0000555f1ddd3a95 in ast_stream_topology_get_stream (topology=0x7f845802f9e8, stream_num=stream_num@entry=4294967295) at stream.c:479
#1  0x0000555f1dcec5d6 in __ast_read (chan=chan@entry=0x7f8438001480, dropaudio=dropaudio@entry=0, dropnondefault=dropnondefault@entry=1) at channel.c:3646
#2  0x0000555f1dced47c in ast_read (chan=chan@entry=0x7f8438001480) at channel.c:4136
#3  0x00007f841025c951 in echo_exec (chan=0x7f8438001480, data=<optimized out>) at app_echo.c:62
#4  0x0000555f1dd72b89 in pbx_exec (c=0x7f8438001480, app=app@entry=0x555f20a26500, data=data@entry=0x0) at pbx_app.c:492
#5  0x0000555f1dd698d5 in pbx_outgoing_exec (data=data@entry=0x7f8438000e20) at pbx.c:7593
#6  0x0000555f1dde960c in dummy_start (data=<optimized out>) at utils.c:1249
#7  0x00007f846b49f494 in start_thread (arg=0x7f83fd923700) at pthread_create.c:333
#8  0x00007f846a0a9acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
{noformat}
Comments:By: Asterisk Team (asteriskteam) 2019-01-24 10:50:18.620-0600

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.
By: Asterisk Team (asteriskteam) 2019-01-24 10:50:19.323-0600

This issue has been automatically restricted and set to a blocker due to being a security type issue. If this is not a security vulnerability issue it will be moved to the appropriate issue type when triaged.
By: Sotiris Ganouris (sotoz) 2019-01-24 11:05:23.042-0600

I added the xml scenario that replicates the issue with sipp. I also added the full debug log for one of the crashes.
By: Sotiris Ganouris (sotoz) 2019-01-24 11:09:42.952-0600

This is a patch that we think it's a workaround to fix this issue.

It basically checks if the stream_num is valid (not an unsigned int) and doesn't allow to reach the stream if it's not ready.

Edit by @kharwell - inline code removed.

By: Kevin Harwell (kharwell) 2019-01-24 15:27:40.114-0600

Thanks for the patch. Unfortunately we cannot accept any code contributions inline and/or in comments. If you have not already done so please sign a license agreement [1] [2] and attach the patch to the issue.

[1] https://wiki.asterisk.org/wiki/display/AST/Digium+License+Agreement
[2] https://issues.asterisk.org/jira/secure/DigiumLicense.jspa
By: Kevin Harwell (kharwell) 2019-01-24 16:05:24.826-0600

Also please attach the audio file used in the scenario.

Thanks!
By: Sotiris Ganouris (sotoz) 2019-01-25 08:47:45.511-0600

Hello, I updated the ticket with the g729 file that can cause the problem. It can be replicated with whatever g729 encoded formated file though.
By: Sotiris Ganouris (sotoz) 2019-01-25 08:49:03.032-0600

I also signed the digium license agreement and I'm waiting for verification so I can submit the patch we propose. Have you had time to check it on your own? I think it's causing a lot of trouble to a lot of people. We've seen that strange behavior from the MERA User Agent.
By: Joshua C. Colp (jcolp) 2019-01-25 08:51:57.441-0600

It's in queue to look at. Once assigned and in progress, that'll be reflected on this issue.
By: George Joseph (gjoseph) 2019-01-29 13:22:44.622-0600

Hi Sotiris,
It looks like your license agreement was approved so go ahead and attach your patch.

By: George Joseph (gjoseph) 2019-01-30 11:51:29.559-0600

We've looked at this issue and while we think it's a serious one, we're not sure if it's really a "security" issue.  There's no way for an unauthenticated attacker to trigger the crash by themselves.  In this case, the remote user agent violates the SDP by sending media using a codec that wasn't in the SDP offer and the crash only happens if the SDP answer is sent back in the 180-Ringing and the media is sent before the 200-OK.   The attacker would have to access asterisk, set up an extension pointing to a remote agent that violates the SDP protocol, then send a call there.

The fix for the crash itself is easy and we can get that out fairly quickly.  If we treat it as a "security" issue there's a lot more work that has to be done before we can make a fix available therrefore would you be OK with us removing the "security" flag from this issue?  
By: Sotiris Ganouris (sotoz) 2019-01-30 13:04:13.431-0600

Hello George, Thank you for your time.

Many VoIP services allow to send SIP traffic for DID numbers to a customer own UAC. With this kind of service someone can easily create a fake account to a service like that, and start sending traffic to a UAC that has the problematic behaviour. With this way he can force asterisk used by the offering service to segfault and cause a lot of trouble. We have already experienced this by a supplier mistake so we investigated and found and reported this issue. As long as one of the parties can somehow crash Asterisk by sending faulty data I think it should be considered a security issue. Let's have it treated as security issue please and we can help you as much as possible where we can.
By: George Joseph (gjoseph) 2019-01-30 13:09:52.942-0600

No worries.  That's the information we were looking for.  I'll attach a patch here for you to test shortly.

By: George Joseph (gjoseph) 2019-01-30 13:38:34.125-0600

Can you test the patch I just attached and see if it fixes the issue for you?  It should prevent frames from ever reaching the code in channel.c when the SDP negotiation fails.

By: Sotiris Ganouris (sotoz) 2019-02-12 09:47:26.964-0600

Hello, we have tested the patch and indeed it fixes the issue. Thank you. Are there plans to release it also for the 15.x branch?
By: Sotiris Ganouris (sotoz) 2019-02-27 03:00:56.899-0600

Hello, any news on that matter?
By: Joshua C. Colp (jcolp) 2019-02-27 05:12:38.282-0600

A security release is in queue and will be happening within the next few days. The change will go into all applicable security supported branches and trigger releases accordingly.
By: Friendly Automation (friendly-automation) 2019-02-28 12:22:55.942-0600

Change 11072 merged by Kevin Harwell:
res_pjsip_sdp_rtp:  Fix return code from apply_negotiated_sdp_stream

[https://gerrit.asterisk.org/c/asterisk/+/11072|https://gerrit.asterisk.org/c/asterisk/+/11072]
By: Friendly Automation (friendly-automation) 2019-02-28 12:23:17.171-0600

Change 11073 merged by Kevin Harwell:
res_pjsip_sdp_rtp:  Fix return code from apply_negotiated_sdp_stream

[https://gerrit.asterisk.org/c/asterisk/+/11073|https://gerrit.asterisk.org/c/asterisk/+/11073]
By: Friendly Automation (friendly-automation) 2019-02-28 12:23:36.831-0600

Change 11071 merged by Kevin Harwell:
res_pjsip_sdp_rtp:  Fix return code from apply_negotiated_sdp_stream

[https://gerrit.asterisk.org/c/asterisk/+/11071|https://gerrit.asterisk.org/c/asterisk/+/11071]
By: Friendly Automation (friendly-automation) 2019-02-28 12:23:48.099-0600

Change 11074 merged by Kevin Harwell:
res_pjsip_sdp_rtp:  Fix return code from apply_negotiated_sdp_stream

[https://gerrit.asterisk.org/c/asterisk/+/11074|https://gerrit.asterisk.org/c/asterisk/+/11074]