Bug 1126692 - gcc: various flaws [fedora-all]
Summary: gcc: various flaws [fedora-all]
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: 20
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: fst_ping=1
Depends On:
Blocks: 1126688 1126691
TreeView+ depends on / blocked
 
Reported: 2014-08-05 05:39 UTC by Murray McAllister
Modified: 2015-01-04 22:41 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Release Note
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-12-06 18:52:20 UTC


Attachments (Terms of Use)

Description Murray McAllister 2014-08-05 05:39:42 UTC
This is an automatically created tracking bug!  It was created to ensure
that one or more security vulnerabilities are fixed in affected versions
of Fedora.

For comments that are specific to the vulnerability please use bugs filed
against the "Security Response" product referenced in the "Blocks" field.

For more information see:
http://fedoraproject.org/wiki/Security/TrackingBugs

When submitting as an update, use the fedpkg template provided in the next
comment(s).  This will include the bug IDs of this tracking bug as well as
the relevant top-level CVE bugs.

Please also mention the CVE IDs being fixed in the RPM changelog and the
fedpkg commit message.

NOTE: this issue affects multiple supported versions of Fedora. While only
one tracking bug has been filed, please correct all affected versions at
the same time.  If you need to fix the versions independent of each other,
you may clone this bug as appropriate.

[bug automatically created by: add-tracking-bugs]

Comment 1 Murray McAllister 2014-08-05 05:39:48 UTC
Use the following template to for the 'fedpkg update' request to submit an
update for this issue as it contains the top-level parent bug(s) as well as
this tracking bug.  This will ensure that all associated bugs get updated
when new packages are pushed to stable.

=====

# bugfix, security, enhancement, newpackage (required)
type=security

# testing, stable
request=testing

# Bug numbers: 1234,9876
bugs=1126688,1126692

# Description of your update
notes=Security fix for 

# Enable request automation based on the stable/unstable karma thresholds
autokarma=True
stable_karma=3
unstable_karma=-3

# Automatically close bugs when this marked as stable
close_bugs=True

# Suggest that users restart after update
suggest_reboot=False

======

Additionally, you may opt to use the bodhi update submission link instead:

https://admin.fedoraproject.org/updates/new/?type_=security&bugs=1126688,1126692

Comment 2 Murray McAllister 2014-08-05 05:40:08 UTC
Adding parent bug 1126691.  Please use this new fedpkg update template when submitting the update:

=====

# bugfix, security, enhancement, newpackage (required)
type=security

# testing, stable
request=testing

# Bug numbers: 1234,9876
bugs=1126692,1126688,1126691

# Description of your update
notes=Security fix for 

# Enable request automation based on the stable/unstable karma thresholds
autokarma=True
stable_karma=3
unstable_karma=-3

# Automatically close bugs when this marked as stable
close_bugs=True

# Suggest that users restart after update
suggest_reboot=False

======

Additionally, you may opt to use the bodhi update submission link instead:

https://admin.fedoraproject.org/updates/new/?type_=security&bugs=1126692,1126688,1126691

Comment 3 Jakub Jelinek 2014-08-05 07:11:02 UTC
How can this affect Fedora 20 when gcc 4.8.x and earlier don't have <regex> implemented at all?

Furthermore, like with glibc regcomp/regexec, passing untrusted regular expressions to the engine is the bug, IMHO adding tight limits on what it can process will mean it will reject regular expressions that could be handled with more CPU or memory when needed.

Comment 4 Murray McAllister 2014-08-05 07:23:11 UTC
Thanks Jakub. It needs to be compiled with "-std=c++11". I was not sure of the rules regarding that (whether it is "supported" or not). If not, I can close these. Sorry for the spam.

Comment 5 Jonathan Wakely 2014-08-05 09:03:32 UTC
The <regex> header exists in GCC 4.8 but it's useless and doesn't work, so the only way it can cause a problem in Fedora is that code trying to use it won't compile. That's not a security issue.

Comment 6 pjp 2014-12-03 18:29:38 UTC
Hello jakub,

Could you please fix this soon?

Comment 7 Jakub Jelinek 2014-12-03 19:02:46 UTC
What exactly you want to see fixed?
<regex> is not usable in GCC 4.8, it is only supported in 4.9, and Fedora 20 does not ship GCC 4.9, only F21 does.
It is certainly not backportable.

Comment 8 pjp 2014-12-06 08:43:02 UTC
  Hello Jakub,

(In reply to Jakub Jelinek from comment #7)
> What exactly you want to see fixed?
> <regex> is not usable in GCC 4.8, it is only supported in 4.9, and Fedora 20
> does not ship GCC 4.9, only F21 does. It is certainly not backportable.

   Well from BZ#1126691#c6 IIUC, since glibc & libstdc++ does not encourage feeding untrusted regular expression to these libraries, it is not a security issue. In that case, since no action is going to be taken against this bug, it'd be better to close it as a non issue, with due comments about it.

   Out of curiosity, what is an 'untrusted' regular expression? As in, when do you say a given 'regex' is not trusted/supported? regex(7) manual has 3 cases which are not recommended. Is there other documentation that can be used to say that, since the said issues of excessive resource consumption are known limitations of the current regex engine, they can not be treated as security issues.

Thank you.

Comment 9 Jakub Jelinek 2014-12-06 08:53:38 UTC
The 4.8 <regex> does nothing, it contains solely a few stubs, but nothing works, any app that would use it would be necessarily completely untested, because it wouldn't know it can't match or search anything ever.

Untrusted regular expression is one that is coming from untrusted sources (from over network, or for programs with elevated priviledges also from command line and/or from files that can be changed by a user without those elevated priviledges) - in security terms an attacker.
The thing is, one can write arbitrarily complex regular expressions that can consume lots of memory and/or CPU time to search.
In some cases it doesn't matter, say grep, sed, awk don't run normally with elevated priviledges, so if you try to search something expensive, it is your problem.  But generally, programs say allowing users to write regular expressions from over the network are just broken and security hazard.
If the regular expressions are under the control of the application and they just search using those regular expressions on untrusted data, it is fine.

Comment 10 pjp 2014-12-06 11:12:35 UTC
(In reply to Jakub Jelinek from comment #9)
> The 4.8 <regex> does nothing, it contains solely a few stubs, but nothing
> works, any app that would use it would be necessarily completely untested,
> because it wouldn't know it can't match or search anything ever.

  I see. ie F20 is not affected at all, F21 is.

> Untrusted regular expression is one that is coming from untrusted sources
> (from over network, or for programs with elevated priviledges also from
> command line and/or from files that can be changed by a user without those
> elevated priviledges) - in security terms an attacker.
> The thing is, one can write arbitrarily complex regular expressions that can
> consume lots of memory and/or CPU time to search.
> In some cases it doesn't matter, say grep, sed, awk don't run normally with
> elevated priviledges, so if you try to search something expensive, it is
> your problem.  But generally, programs say allowing users to write regular
> expressions from over the network are just broken and security hazard.
> If the regular expressions are under the control of the application and they
> just search using those regular expressions on untrusted data, it is fine.

  Well that is, an application using untrusted user input, which is always frowned upon.

However in this case, an application is merely using services of regex(7) engine, which seems to crash for some inputs, as indicated in the original report:

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

An application could not have means to define what is an acceptable regex and what is not. Secondly, the fix/patch for this issue needs to be applied in the C/C++ standard library, so that it returns an exception or error code to the applications, instead of dying and killing applications from a crash. IMO, it is an issue in the regex engine implementation and not user applications.

Is this a security issue in the standard library?

  IMO Yes, because the original report above talks about possible stack overflow and comment BZ#1126688#c0 mentions potential code execution. Even if a far remote, it is still a possibility.

Comment 11 Jakub Jelinek 2014-12-06 11:24:40 UTC
IMHO the fulldiscloser report is just flawed.  If libstdc++ (or any other regex engine) attempts to impose some limits (how, perhaps {99} is acceptable, but {100} is not, but you can have ((.*){99}){99} and arbitrary other number of variants), then either there will be always some other way to achieve huge memory or CPU time uses, consider e.g. regex for looking for long palindromes,
e.g. (.*)(.*)(.*)(.*)(.*)(.*)(.*)(.*)(.*).*\9\8\7\6\5\4\3\2\1, or the limitations will be so strict that they will forbid many valid cases too.
So IMNSHO none of this is a security problem, the security bug is feeding untrusted regular expressions to the regular expression engines.

Comment 12 Jonathan Wakely 2014-12-06 16:17:11 UTC
I agree with Jakub, there is nothing to fix here (especially since it's reported against F20 which doesn't even include a working implementation of <regex>).

Can we just close this now?

Comment 13 pjp 2014-12-06 17:58:21 UTC
(In reply to Jakub Jelinek from comment #11)
> IMHO the fulldiscloser report is just flawed.  If libstdc++ (or any other
> regex engine) attempts to impose some limits (how, perhaps {99} is
> acceptable, but {100} is not, but you can have ((.*){99}){99} and arbitrary
> other number of variants), then either there will be always some other way
> to achieve huge memory or CPU time uses, consider e.g. regex for looking for
> long palindromes,
> e.g. (.*)(.*)(.*)(.*)(.*)(.*)(.*)(.*)(.*).*\9\8\7\6\5\4\3\2\1, or the
> limitations will be so strict that they will forbid many valid cases too.

  True, I understand. It's virtually impossible to define which regex is acceptable and which not. That is why I was curious to know how would you do that.

> So IMNSHO none of this is a security problem, the security bug is feeding
> untrusted regular expressions to the regular expression engines.

   Well, feeding untrusted input to any application is a security bug. Just that in this case maybe input can not be sanitized for its resource consumption.

(In reply to Jonathan Wakely from comment #12)
> I agree with Jakub, there is nothing to fix here (especially since it's
> reported against F20 which doesn't even include a working implementation of
> <regex>).
> 
> Can we just close this now?

  Sure! As said in comment #8 above, since no action is going to be taken against this bug, it'd be better to close it as a non issue, with due comment about it.

Thank you.


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