Re: CVE request: issues in ISO C++ 2011 regex library

[Maksymilian A <max () cert cx>]

Not taking into account the vulnerabilities prior to gcc 4.9.1, one
CVE can be considered reasonable assignment CVE for a missing
implementation of error_stack error_space and error_complexity. Lack
of protection against resource exhaustion in official release, will
lead to situations like in glibc.

proftpd glibc remote denial of service exploit
http://cert.cx/stuff/proftpd.gnu.c

There is many vendors what uses remotely RE.

Maksymilian Arciemowicz
http://cxsecurity.com/


2014-08-07 9:56 GMT+02:00 Murray McAllister <mmcallis () redhat com>:
> On 08/06/2014 04:36 AM, Rich Felker wrote:
> > On Tue, Aug 05, 2014 at 03:50:32PM +1000, Murray McAllister wrote:
> > > Hello,
> > >
> > > Maksymilian Arciemowicz reported a number of issues in the ISO C++
> > > 2011 regex libraries:
> > >
> > > http://seclists.org/fulldisclosure/2014/Aug/1
> > >
> > > Bugs:
> > >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61601
> > >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582
> > >
> > > http://llvm.org/bugs/show_bug.cgi?id=20291
> > >
> > > For the memory corruption bug (61582), there seems to be more than
> > > one issue here (at least a heap-based buffer overflow and a stack
> > > overflow of some sort). Can a single CVE be assigned, or do you need
> > > specific details for each issue (I don't currently have those)?
> > >
> > > With GCC 4.8 in Fedora, the affected program needs to be compiled
> > > using the "-std=c++11" option.
> >
> >
> > I think this issue is mis-named. "The ISO C++ 2011 regex library" is a
> > specfication, not an implementation, and a vulnerability in it would
> > be a fundamental flaw in the API design (analogous to gets in C). It
> > seems like this CVE request is for one or more GCC/libstdc++ bugs, and
> > it should be identified as such.
> >
> > Rich
>
> Thanks for pointing that out, and sorry for the confusion!
>
> There is some discussion in
> https://bugzilla.redhat.com/show_bug.cgi?id=1126691 about why these should
> not be treated as security issues.
>
> Cheers,
>
> --
> Murray McAllister / Red Hat Product Security