Asterisk
  1. Asterisk
  2. ASTERISK-26272

chan_sip: File descriptors leak (UDP sockets)

    Details

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

      1. ASTERISK-26272-11.patch
        3 kB
        Corey Farrell
      2. ASTERISK-26272-13.patch
        3 kB
        Corey Farrell
      3. sipp-scenario.xml
        4 kB
        Etienne Lessard
      4. sipp-users.csv
        0.1 kB
        Etienne Lessard

        Issue Links

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

          Hide
          Asterisk Team added a comment -

          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.

          Show
          Asterisk Team added a comment - 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 .
          Hide
          Etienne Lessard added a comment -

          sipp scenario attached. I've run it as:

          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
          

          (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)

          Show
          Etienne Lessard added a comment - sipp scenario attached. I've run it as: 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 (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)
          Hide
          Corey Farrell added a comment -

          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.

          Show
          Corey Farrell added a comment - 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.
          Hide
          Rusty Newton added a comment -

          Thanks for taking this on Corey Farrell !

          Show
          Rusty Newton added a comment - Thanks for taking this on Corey Farrell !
          Hide
          Corey Farrell added a comment -

          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.

          Show
          Corey Farrell added a comment - 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.
          Hide
          Corey Farrell added a comment -

          Rusty Newton, I've attached patches in 'git am' format, let me know if anything more is needed from me.

          Show
          Corey Farrell added a comment - Rusty Newton , I've attached patches in 'git am' format, let me know if anything more is needed from me.
          Hide
          Rusty Newton added a comment -

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

          Show
          Rusty Newton added a comment - Thanks! Looks good for now. This is near the top of our queue.

            People

            • Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: