[asterisk-bugs] [JIRA] (ASTERISK-20658) Blindly doing alloca (or strdupa) on potentially large user input is bad

[Matt Jordan (JIRA)]

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

Matt Jordan updated ASTERISK-20658:
-----------------------------------

    Security:     (was: Reporter, Bug Marshals, and Digium)
    
> Blindly doing alloca (or strdupa) on potentially large user input is bad
> ------------------------------------------------------------------------
>
>                 Key: ASTERISK-20658
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20658
>             Project: Asterisk
>          Issue Type: Bug
>    Affects Versions: 1.8.18.0, 10.10.0, 10.10.0-digiumphones, 11.0.1
>            Reporter: Walter Doekes
>            Severity: Critical
>      Target Release: 1.8.19.1, 10.11.1, 10.11.1-digiumphones, 11.1.1
>
>         Attachments: ASTERISK-20658_res_jabber.c.patch, issueA20658_dont_process_overlong_config_lines.patch, issueA20658_func_realtime_limit.patch, issueA20658_http_postvars_use_malloc2.patch, issueA20658_limit_sip_packet_size3.patch, issueA20658_sanitize_app_mysql.patch, issueA20658_view_allocas.patch
>
>
> 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.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira