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]
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
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
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.
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.
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.
Hello jakub, Could you please fix this soon?
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.
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.
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.
(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.
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.
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?
(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.