Details
-
Type:
Bug
-
Status: Closed
-
Severity:
Major
-
Resolution: Fixed
-
Affects Version/s: 11.23.0, 13.5.0, 13.10.0, GIT
-
Component/s: Channels/chan_sip/General
-
Labels:None
-
Environment:Debian 8 i686
-
Frequency of Occurrence:Constant
Description
Given I have the following extensions.conf:
[default] exten = 1234,1,Hangup()
Given I have the following sip.conf:
[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
When the following SIP scenario occurs (more details in attached sipp scenario):
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
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.
Issue Links
- is a clone of
-
SWP-9145 Loading...
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 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.