Bug 1126691 - gcc: resource consumption issue in libstdc++ C++ regex library
Summary: gcc: resource consumption issue in libstdc++ C++ regex library
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1126692
Blocks: 1126694
TreeView+ depends on / blocked
 
Reported: 2014-08-05 05:38 UTC by Murray McAllister
Modified: 2019-09-29 13:20 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-01-21 16:45:19 UTC


Attachments (Terms of Use)

Description Murray McAllister 2014-08-05 05:38:49 UTC
Maksymilian Arciemowicz reported a resource consumption issue in the libstdc++ C++ regex library. If an attacker were able to make an application using this library process a specially-crafted regular expression, it could cause the application to consume excessive system resources.

Original report:

http://seclists.org/fulldisclosure/2014/Aug/1

Upstream bug:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61601

Currently on Fedora, this requires compiling the affected program with the experimental ISO C++ 2011 support by using the "-std=c++11" option.

Comment 1 Murray McAllister 2014-08-05 05:40:10 UTC
Created gcc tracking bugs for this issue:

Affects: fedora-all [bug 1126692]

Comment 2 Murray McAllister 2014-08-05 05:51:28 UTC
CVE request: http://www.openwall.com/lists/oss-security/2014/08/05/4

Comment 3 Jonathan Wakely 2014-08-05 09:23:35 UTC
The upstream bug only applies to GCC 4.9 because std::regex is unusable in GCC 4.8

Comment 4 Jakub Jelinek 2014-08-05 09:26:55 UTC
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.

Comment 5 Jonathan Wakely 2014-08-05 09:42:01 UTC
(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.

Comment 6 Jakub Jelinek 2014-08-05 09:44:15 UTC
(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.

Comment 7 Murray McAllister 2014-08-07 07:55:36 UTC
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

Comment 8 Maksymilian 2014-08-07 08:36:13 UTC
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.

Comment 9 Maksymilian 2014-08-12 12:38:47 UTC
You can't exclude (AV:N). It's very hard to determine how <regex> will be used in future (eg. Kaspersky uses regex remotely).

Comment 10 Stefan Cornelius 2014-08-12 13:55:41 UTC
(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)

Comment 11 Jonathan Wakely 2014-08-12 14:02:03 UTC
There's already an upstream bug (several in fact) reported by Maksymilian, it's linked to in comment 0


Note You need to log in before you can comment on or make changes to this bug.