[asterisk-bugs] [JIRA] (ASTERISK-26272) chan_sip: File descriptors leak (UDP sockets)

[Joshua Colp (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-26272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joshua Colp closed ASTERISK-26272.
----------------------------------


> chan_sip: File descriptors leak (UDP sockets)
> ---------------------------------------------
>
>                 Key: ASTERISK-26272
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26272
>             Project: Asterisk
>          Issue Type: Bug
>          Components: Channels/chan_sip/General
>    Affects Versions: 11.23.0, 13.5.0, 13.10.0, GIT
>         Environment: Debian 8 i686
>            Reporter: Etienne Lessard
>            Assignee: Joshua Colp
>      Target Release: 11.23.1, 13.11.1, 14.0.0, GIT
>
>         Attachments: ASTERISK-26272-11.patch, ASTERISK-26272-13.patch, sipp-scenario.xml, sipp-users.csv
>
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.2#6252)