[Home]

Summary:ASTERISK-26272: chan_sip: File descriptors leak (UDP sockets)
Reporter:Etienne Lessard (hexanol)Labels:
Date Opened:2016-08-05 11:05:40Date Closed:2016-09-08 09:27:49
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:11.23.0 13.5.0 13.10.0 GIT Frequency of
Occurrence
Constant
Related
Issues:
Environment:Debian 8 i686Attachments:( 0) ASTERISK-26272-11.patch
( 1) ASTERISK-26272-13.patch
( 2) sipp-scenario.xml
( 3) sipp-users.csv
Description:Given I have the following extensions.conf:
{noformat}
[default]
exten = 1234,1,Hangup()
{noformat}
Given I have the following sip.conf:
{noformat}
[general]
udpbindaddr = 0.0.0.0
allowguest = no
allowoverlap = yes

[alice]
host = 10.34.0.254
context = default
callerid = "Alice" <1001>
secret = alice
type = friend
{noformat}
When the following SIP scenario occurs (more details in attached sipp scenario):
{noformat}
Alice: INVITE sip:123
asterisk: 401 Unauthorized
Alice: ACK
Alice: INVITE sip:123 (with auth)
asterisk: 484 Address Incomplete
Alice: ACK
Alice: INVITE sip:123
asterisk: 401 Unauthorized
Alice: ACK
Alice: INVITE sip:123 (with auth)
asterisk: 484 Address Incomplete
Alice: ACK
{noformat}
Then asterisk leaks one RTP instance, which leaks 2 UDP sockets.

There might be other scenarios to reproduce the leak: the one I've built is similar to what I've seen on an asterisk used in production. On that production server, Alice user-agent was a "KIRK Wireless Server 600v3".

I don't know if the SIP scenario is valid, that said even if it's not, asterisk should not leaks file descriptors in this scenario.

I don't know if this should be considered a security issue: a peer which is authorized to sent SIP INVITE to an asterisk configured with chan_sip using overlap dialing can then create a denial-of-service attack by exhausting all the file descriptors available for the asterisk process.

I've reproduced the bug on both asterisk 13.5.0 (where the leak was originally detected) and 13.10.0.
Comments:By: Asterisk Team (asteriskteam) 2016-08-05 11:05:40.973-0500

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

By: Etienne Lessard (hexanol) 2016-08-05 12:05:09.287-0500

sipp scenario attached. I've run it as:
{noformat}
sipp -inf sipp-users.csv -sf sipp-scenario.xml -p 5060 -i 10.34.0.254 -r 1.0 -rp 1000 10.34.0.1
{noformat}

(where 10.34.0.1 is the IP address where my asterisk is running and 10.34.0.254 is the local IP address of the machine on which I'm running sipp)

By: Corey Farrell (coreyfarrell) 2016-08-05 20:29:20.567-0500

Using REF_DEBUG I was able to confirm this bug against latest 11.  I tested by adding '-m 1' to the sipp command-line, one instance of {{ast_rtp_instance_new}} leaked (the second one).  It looks like {{dialog_initialize_rtp}} is being called multiple times on the same dialog causing the previous RTP instances to be leaked.

By: Rusty Newton (rnewton) 2016-08-08 08:12:10.788-0500

Thanks for taking this on [~coreyfarrell] !

By: Corey Farrell (coreyfarrell) 2016-08-08 10:14:13.257-0500

I've attached patches for 11 and 13.  Verified with the provided configs / sipp scenario the issue is fixed.  Also verified v11 testsuite tests/channels/SIP with REF_DEBUG enabled has the same success/failure as before.

On a side note, this bug can be reproduced without configuring {{allowoverlap=yes}} - it seems this is the default.  I'm not sure I agree with this, feel like the default setting should not make it possible to data-mine the default context.  IE I can dial 1@yourserver, 2@yourserver, etc to find which prefix is in use, and so on until I find valid dial patterns.

By: Corey Farrell (coreyfarrell) 2016-08-11 22:31:48.227-0500

[~rnewton], I've attached patches in 'git am' format, let me know if anything more is needed from me.

By: Rusty Newton (rnewton) 2016-08-15 09:43:41.933-0500

Thanks! Looks good for now. This is near the top of our queue.