Bug 1126691

Created gcc tracking bugs for this issue:

Affects: fedora-all [bug 1126692]

CVE request: http://www.openwall.com/lists/oss-security/2014/08/05/4

The upstream bug only applies to GCC 4.9 because std::regex is unusable in GCC 4.8

That said, are those changes backportable from trunk to 4.9, and even if they are, is it desirable to tell people they can feed untrusted regular expressions to the <regex> engine?  For glibc we just say that people should never do that, because the DFA with very complex regular expressions can take unbounded amounts of memory and CPU time.

(In reply to Jakub Jelinek from comment #4)
> That said, are those changes backportable from trunk to 4.9,

The changes on trunk to try and reject crazy inputs should be possible to backport.

> and even if
> they are, is it desirable to tell people they can feed untrusted regular
> expressions to the <regex> engine?

No, that's never going to be a good idea.

> For glibc we just say that people should
> never do that, because the DFA with very complex regular expressions can
> take unbounded amounts of memory and CPU time.

The same applies to std::regex.

(In reply to Jonathan Wakely from comment #5)
> > and even if
> > they are, is it desirable to tell people they can feed untrusted regular
> > expressions to the <regex> engine?
> 
> No, that's never going to be a good idea.
> 
> > For glibc we just say that people should
> > never do that, because the DFA with very complex regular expressions can
> > take unbounded amounts of memory and CPU time.
> 
> The same applies to std::regex.

Then this isn't a security issue and should not be treated as such.

As pointed out by Rich Felker, this is not a flaw in the "ISO C++ 2011 regex library" specification, but rather a GCC/libstdc++ bug:

http://www.openwall.com/lists/oss-security/2014/08/05/11

One important question: Is GCC going implement missing error_complexity error_stack and error_spack?
Thinking that people know that they can't safe use regcomp() and std::regex causes to situation like this

https://support.zabbix.com/browse/ZBX-4625

new C++11 should solve this problem, however specification is badly defined.

You can't exclude (AV:N). It's very hard to determine how <regex> will be used in future (eg. Kaspersky uses regex remotely).

(In reply to Jakub Jelinek from comment #6)
> (In reply to Jonathan Wakely from comment #5)
> > > and even if
> > > they are, is it desirable to tell people they can feed untrusted regular
> > > expressions to the <regex> engine?
> > 
> > No, that's never going to be a good idea.
> > 
> > > For glibc we just say that people should
> > > never do that, because the DFA with very complex regular expressions can
> > > take unbounded amounts of memory and CPU time.
> > 
> > The same applies to std::regex.
> 
> Then this isn't a security issue and should not be treated as such.

Yeah, historically, it was always a bad idea to use untrusted regexes. I also think that this applies here ...so I tend to agree that we shouldn't handle this as security issue (although I don't expect it at this point, the security community as a whole may decide differently on this matter. If that's the case, I'm willing to revisit this issue).

Jakub, can you file normal gcc bugs for this before I close these security bugs down? (I'll do it myself in a day or two, but I'm not exactly sure about how you guys like your bugs, so it's less messy to give you a chance to do it properly yourself)

There's already an upstream bug (several in fact) reported by Maksymilian, it's linked to in comment 0