Summary: | ASTERISK-26272: chan_sip: File descriptors leak (UDP sockets) | ||
Reporter: | Etienne Lessard (hexanol) | Labels: | |
Date Opened: | 2016-08-05 11:05:40 | Date Closed: | 2016-09-08 09:27:49 |
Priority: | Major | Regression? | |
Status: | Closed/Complete | Components: | Channels/chan_sip/General |
Versions: | 11.23.0 13.5.0 13.10.0 GIT | Frequency of Occurrence | Constant |
Related Issues: | |||
Environment: | Debian 8 i686 | Attachments: | ( 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. |