Asterisk
  1. Asterisk
  2. ASTERISK-20658

Blindly doing alloca (or strdupa) on potentially large user input is bad

    Details

    • Type: Bug Bug
    • Status: Closed
    • Severity: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.8.18.0, 10.10.0, 10.10.0-digiumphones, 11.0.1
    • Target Release Version/s: 1.8.19.1, 10.11.1, 10.11.1-digiumphones, 11.1.1
    • Component/s: None
    • Labels:
      None
    • Regression:
      No

      Description

      I recently removed a potential user initiated crash by removing unnecessary ast_strdupa's in this patch.
      http://lists.digium.com/pipermail/asterisk-commits/2012-October/057328.html

      The problem is that alloca() does not check whether things will fit in the stack. If they don't fit, asterisk will simply segfault.
      This wouldn't be so much of a problem, if it weren't for the limited stack size:

      /* default 500kB or 110kB */
      #define AST_STACKSIZE (((sizeof(void *) * 8 * 8) - 16) * 1024)
      #define AST_BACKGROUND_STACKSIZE (((sizeof(void *) * 8 * 2) - 16) * 1024)
      pthread_attr_setstacksize(attr, stacksize ? stacksize : AST_STACKSIZE);
      

      Before the mentioned patch, sending a SIP body that was too large (e.g. 700kB) would trigger the crash. Unfortunately, that isn't the only place where user data is fed to alloca and friends directly.

      Anywhere where one of ast_alloca, ast_str_alloca and ast_strdupa is used, case should be taken that the data isn't too large.

      While checking for issues in the SIP module, I've found at least three, but I'm pretty sure there are more. All of those are only exploitable if you're using TCP (or TLS) because (fragmented) UDP won't allow packet sizes that big.

      • Allow: BIG_STRING
      • Content-Type: multipart/mixed;boundary="BIG_STRING"
      • sdp body: o=BIG_STRING\nm=audio\n

      The easy fix is to cap a SIP packet size to something reasonable like 20K. That's what the attached patch [1] does.

      Patch [2] makes the alloca's visible. It could be used to scan for other potential problems. (I've rewritten the ast_verbose alloca to use C99 variable length arrays. That suffers from the same problem, but it declutters the output.)

      [1] issueA20658_limit_sip_packet_size.patch
      [2] issueA20658_view_allocas.patch

      Regards,
      Walter Doekes
      OSSO B.V.

      1. ASTERISK-20658_res_jabber.c.patch
        0.8 kB
        Mark Michelson
      2. issueA20658_dont_process_overlong_config_lines.patch
        0.9 kB
        Walter Doekes
      3. issueA20658_func_realtime_limit.patch
        1 kB
        Walter Doekes
      4. issueA20658_http_postvars_use_malloc2.patch
        1 kB
        Walter Doekes
      5. issueA20658_limit_sip_packet_size3.patch
        6 kB
        Walter Doekes
      6. issueA20658_sanitize_app_mysql.patch
        5 kB
        Walter Doekes
      7. issueA20658_view_allocas.patch
        3 kB
        Walter Doekes

        Issue Links

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

          Activity

          Walter Doekes created issue -
          Erin Spiceland made changes -
          Field Original Value New Value
          Security None [ 10113 ] Reporter, Bug Marshals, and Digium [ 10110 ]
          Walter Doekes made changes -
          Summary EDIT_THIS Blindly doing alloca (or strdupa) on potentially large user input is bad
          Description EDIT_THIS I recently removed a potential user initiated crash by removing unnecessary ast_strdupa's in this patch.
          http://lists.digium.com/pipermail/asterisk-commits/2012-October/057328.html

          The problem is that alloca() does not check whether things will fit in the stack. If they don't fit, asterisk will simply segfault.
          This wouldn't be so much of a problem, if it weren't for the limited stack size:
          {code}
          /* default 500kB or 110kB */
          #define AST_STACKSIZE (((sizeof(void *) * 8 * 8) - 16) * 1024)
          #define AST_BACKGROUND_STACKSIZE (((sizeof(void *) * 8 * 2) - 16) * 1024)
          pthread_attr_setstacksize(attr, stacksize ? stacksize : AST_STACKSIZE);
          {code}


          Before the mentioned patch, sending a SIP body that was too large (e.g. 700kB) would trigger the crash. Unfortunately, that isn't the only place where user data is fed to alloca and friends directly.

          Anywhere where one of ast_alloca, ast_str_alloca and ast_strdupa is used, case should be taken that the data isn't too large.

          While checking for issues in the SIP module, I've found at least three, but I'm pretty sure there are more. All of those are only exploitable if you're using TCP (or TLS) because (fragmented) UDP won't allow packet sizes that big.

          - Allow: BIG_STRING
          - Content-Type: multipart/mixed;boundary="BIG_STRING"
          - sdp body: o=BIG_STRING\nm=audio\n

          The easy fix is to cap a SIP packet size to something reasonable like 20K. That's what the attached patch [1] does.

          Patch [2] makes the alloca's visible. It could be used to scan for other potential problems. (I've rewritten the ast_verbose alloca to use C99 variable length arrays. That suffers from the same problem, but it declutters the output.)

          [1] issueA20658_limit_sip_packet_size.patch
          [2] issueA20658_view_allocas.patch

          Regards,
          Walter Doekes
          OSSO B.V.
          Walter Doekes made changes -
          Attachment issueA20658_limit_sip_packet_size.patch [ 45281 ]
          Walter Doekes made changes -
          Attachment issueA20658_view_allocas.patch [ 45282 ]
          Matt Jordan made changes -
          Status Triage [ 10000 ] Open [ 1 ]
          Matt Jordan made changes -
          Affects Version/s 11.0.1 [ 11681 ]
          Affects Version/s 10.10.0-digiumphones [ 11566 ]
          Affects Version/s 10.10.0 [ 11565 ]
          Affects Version/s 1.8.18.0 [ 11567 ]
          Matt Jordan made changes -
          Severity Major [ 3 ] Critical [ 2 ]
          Matt Jordan made changes -
          Link This issue is the original version of this clone: ASTERISK-20660 [ ASTERISK-20660 ]
          Walter Doekes made changes -
          Attachment issueA20658_limit_sip_packet_size2.patch [ 45320 ]
          Walter Doekes made changes -
          Attachment issueA20658_limit_sip_packet_size.patch [ 45281 ]
          Walter Doekes made changes -
          Attachment issueA20658_http_postvars_use_malloc.patch [ 45443 ]
          Walter Doekes made changes -
          Walter Doekes made changes -
          Attachment issueA20658_http_postvars_use_malloc.patch [ 45443 ]
          Walter Doekes made changes -
          Walter Doekes made changes -
          Walter Doekes made changes -
          Attachment issueA20658_limit_sip_packet_size2.patch [ 45320 ]
          Mark Michelson made changes -
          Attachment ASTERISK-20658_res_jabber.c.patch [ 45478 ]
          Walter Doekes made changes -
          Walter Doekes made changes -
          Michael Spiceland made changes -
          Link This issue is related to PQ-1328 [ PQ-1328 ]
          Matt Jordan made changes -
          Security Reporter, Bug Marshals, and Digium [ 10110 ]
          Matt Jordan made changes -
          Target Release Version/s 11.1.1 [ 11801 ]
          Target Release Version/s 10.11.1-digiumphones [ 11803 ]
          Target Release Version/s 10.11.1 [ 11802 ]
          Target Release Version/s 1.8.19.1 [ 11804 ]
          Matt Jordan made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Resolution Fixed [ 1 ]
          Matt Jordan made changes -
          Link This issue must be completed before resolving ASTERISK-20809 [ ASTERISK-20809 ]
          Matt Jordan made changes -
          Link This issue must be completed before resolving ASTERISK-20807 [ ASTERISK-20807 ]
          Matt Jordan made changes -
          Link This issue must be completed before resolving ASTERISK-20808 [ ASTERISK-20808 ]

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: