Asterisk
  1. Asterisk
  2. ASTERISK-13525

Asterisk crash with looped request and pedantic=yes

    Details

    • Type: Bug Bug
    • Status: Closed
    • Severity: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Target Release Version/s: None
    • Labels:
      None
    • Mantis ID:
      14417
    • Regression:
      No

      Description

      Hi!

      When Asterisk sends a message to itself (e.g. bad configuration, or by an attacker if Asterisk sends a request to an external domain which resolves to Asterisk again), when pedantic=yes, Asterisk crashes when comparing the URIs.

      At the end of sip_uri_cmp(const char *input1, const char *input2) the headers will be compared.

      if (sip_uri_headers_cmp(headers1, headers2))

      { return 1; }

      The problem is that if there are no headers, headers1/2 are 0x0. But the sip_uri_headers_cmp() function accesses the pointers without checking for null pointers --> segfault.

                • ADDITIONAL INFORMATION ******

      Workaround: check if headers1/2 is not NULL before calling sip_uri_headers_cmp() (or check inside sip_uri_headers_cmp).

      I have set the status to private as I think you can easily crash severs using this bug.

        Activity

        Hide
        Mark Michelson added a comment -

        Thanks for reporting this. First of all, the problem has already been fixed in all Asterisk branches as of 6 Feb.

        As far as the security-related aspect of it, I realize that the crash is triggered by a call occurring from an external source, but I'm failing to see how this could be exploited by someone malicious. The spiralled INVITE has to have come from Asterisk to begin with, so it's not as if someone could spoof the request. Can you shed some light on how you think this might be exploitable?

        Edit: I should be more specific than just giving a date for when this was fixed. In the 1.4 branch, this was fixed with revision 174082. This commit was made to fix issue ASTERISK-12768

        Show
        Mark Michelson added a comment - Thanks for reporting this. First of all, the problem has already been fixed in all Asterisk branches as of 6 Feb. As far as the security-related aspect of it, I realize that the crash is triggered by a call occurring from an external source, but I'm failing to see how this could be exploited by someone malicious. The spiralled INVITE has to have come from Asterisk to begin with, so it's not as if someone could spoof the request. Can you shed some light on how you think this might be exploitable? Edit: I should be more specific than just giving a date for when this was fixed. In the 1.4 branch, this was fixed with revision 174082. This commit was made to fix issue ASTERISK-12768
        Hide
        klaus3000 added a comment -

        For example the attacker is a customer of a SIP provider which uses Asterisk. IF the service provider has set pedantic=yes, the attacker can wait for an incoming call - this means the provider's Asterisk sends an INVITE to the attacker. Then the attacks just has to send the INVITE back to the Asterisk server (without changing anything). As the RURI in both requests are identical the bug is triggered and the service providers Asterisk crashes.

        There could be also examples. E.g. the attacker is connected to the DUNDI network and announces reachability for every requested number via SIP. Then it just sends back the unmodified INVITE. The the caller has pedantic=Yes --> crash.

        ...

        Show
        klaus3000 added a comment - For example the attacker is a customer of a SIP provider which uses Asterisk. IF the service provider has set pedantic=yes, the attacker can wait for an incoming call - this means the provider's Asterisk sends an INVITE to the attacker. Then the attacks just has to send the INVITE back to the Asterisk server (without changing anything). As the RURI in both requests are identical the bug is triggered and the service providers Asterisk crashes. There could be also examples. E.g. the attacker is connected to the DUNDI network and announces reachability for every requested number via SIP. Then it just sends back the unmodified INVITE. The the caller has pedantic=Yes --> crash. ...
        Hide
        Joshua Colp added a comment -

        Security advisory (AST-2009-002) has been completed and sent out. Asterisk 1.4.23.2 has already been released for this. Closing out.

        Show
        Joshua Colp added a comment - Security advisory (AST-2009-002) has been completed and sent out. Asterisk 1.4.23.2 has already been released for this. Closing out.

          People

          • Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development