[asterisk-bugs] [JIRA] (ASTERISK-25397) [patch]chan_sip: File descriptor leak with non-default timert1

[Matt Jordan (JIRA)]

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

Matt Jordan updated ASTERISK-25397:
-----------------------------------

    Security:     (was: Reporter, Bug Marshals, and Digium)

> [patch]chan_sip: File descriptor leak with non-default timert1
> --------------------------------------------------------------
>
>                 Key: ASTERISK-25397
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25397
>             Project: Asterisk
>          Issue Type: Bug
>          Components: Channels/chan_sip/General
>    Affects Versions: 1.8.32.3, 11.19.0, 12.8.2, 13.5.0
>            Reporter: Alexander Traud
>            Assignee: Unassigned
>            Severity: Critical
>      Target Release: 11.21.1, 13.7.1
>
>         Attachments: jira_asterisk_25397_v13.patch, jira_asterisk_25397_v13_v2.patch, siptimerA_overflow.patch
>
>
> From the issue reporter:
> {quote}
> For T1, RFC 3261 suggests a default of 500 ms. For mobile networks, 3GPP TS
> 24.229 recommends 2000 ms. Nokia used 3000 ms. Therefore and because of
> personal experience, I changed the parameter timert1 in my sip.conf to a
> value higher than 1246. Since then, around 1000 file descriptors (UDP ports)
> leak every 10 days, because my SIP server is attacked/scanned continuously.
> Thanks to CLI "core show fd" and "sip show sched", I was able to break it
> down to a counter overflow in the variable "siptimer_a". That variable was
> treated as unsigned although it is signed. After fixing this, I noticed
> another counter overflow in "sip_pkt->timer_a". I was able to remove
> "sip_pkt->timer_a" completely because it can be calculated from
> "sip_pkt->retrans" at any time. Because of this, the scheduler is not called
> with a negative number anymore. Because of this, the scheduler does not
> convert this negative number into a silly high number, effectively never
> releasing the UDP port. Therefore, I do not face a file descriptor leak
> anymore. To catch similar negative-value issues, I added a WARNING within
> the scheduler.
> Steps to reproduce
> 00. Ubuntu 14.04 LTS
> 01. apt-get install build-essential libssl-dev libncurses-dev libnewt-dev
> libxml2-dev linux-headers-$(uname -r) libsqlite3-dev uuid-dev libjansson-dev
> libbfd-dev
> 02. wget
> downloads.asterisk.org/pub/telephony/asterisk/asterisk-12-current.tar.gz
> 03. tar zxf asterisk*
> 04. cd asterisk*
> 05. ./configure
> 06. make menuselect.makeopts
> 07. ./menuselect/menuselect --enable DONT_OPTIMIZE --enable
> BETTER_BACKTRACES --enable DEBUG_FD_LEAKS
> 08. make install config samples
> 09. changed /etc/asterisk/sip.conf to include timert1=1250
> 10. CLI: core set debug 4
> 11. sendip -p ipv4 -is 89.163.146.62 -p udp -us 5071 -ud 5060 -f
> ./message.txt 127.0.0.1
> You do not have to change the last command and the message to your IP
> addresses. By the way, that is a message send by one of my spammers.
> Expected behavior
> After the re-transmission of the status "404 Not Found", the related UDP
> ports should be closed and the corresponding file descriptors released.
> Actual behavior
> CLI: core show fd
> CLI: sip show sched
> show one packet and two (sometimes only one?) leaked UDP port, even after
> days. The scheduler has one outstanding packet with a re-schedule in more
> than 25 days.
> Additional Notes
> SIP timers got introduced with the feature request/report
> ASTERISK-4257/-5187, supplied by Olle Johansson. Therefore, Olle is CCed on
> this report. Perhaps Olle is able to look-over and comment my proposed patch
> as well. Because this code was added exactly ten years ago, I am curious why
> I am the first one reporting this issue. Perhaps, I misunderstand something
> or the cause is somewhat different (the amount of re-transmissions changed
> since the original code).
> This E-mail is not encrypted because the Asterisk team had issues with my
> PGP mails in the past. Unfortunately, I was not told which PGP software the
> Asterisk team is using. Therefore, I could not debug this. Anyway, this
> issue is already exploited by hackers - I learned about this when my server
> ran out of available file descriptors - therefore this issue is somewhat
> public.
> {quote}



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