oss-security - Re: two vulns in uClibc-0.9.33.2

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANO=Ty2QDq=85miG_W0EixwAsVRfO_8bExCHPNX1D5Coe6UBaw@mail.gmail.com>
Date: Fri, 16 Jun 2017 15:09:09 -0600
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security <oss-security@...ts.openwall.com>
Subject: Re: two vulns in uClibc-0.9.33.2

On Fri, Jun 16, 2017 at 2:44 PM, Seth Arnold <seth.arnold@...onical.com>
wrote:

> 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.
>

I would say it depends, are they actually exploitable in a realistic sense
by an attacker? (e.g. dir globbing on ftp servers should not let anonymous
ftp users eat all the CPU/RAM).


>
> 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?
>

I would also suggest we look at common usage. E.g.:

https://docs.python.org/2/library/pickle.html

Warning


The pickle <https://docs.python.org/2/library/pickle.html#module-pickle> module
is not secure against erroneous or maliciously constructed data. Never
unpickle data received from an untrusted or unauthenticated source.


However:


http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=python+pickle


and if you search github for socket and pickle... well.. yeah.


>
> Thanks
>



-- 

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert@...hat.com

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.