In the Phrack article "A Eulogy for Format Strings", a researcher using nickname "Captain Planet" reported an integer overflow flaw in the format string protection mechanism offered by FORTIFY_SOURCE. A remote attacker could provide a specially crafted executable, leading to FORTIFY_SOURCE format string protection mechanism bypass, when executed. References: http://www.phrack.org/issues.html?issue=67&id=9#article Upstream bug and Kees Cook's proposed patches: http://sourceware.org/bugzilla/show_bug.cgi?id=13656 http://sourceware.org/ml/libc-alpha/2012-02/msg00023.html http://sourceware.org/ml/libc-alpha/2012-02/msg00012.html http://sourceware.org/ml/libc-alpha/2012-02/msg00073.html
*** Bug 794763 has been marked as a duplicate of this bug. ***
A CVE identifier of CVE-2012-0864 has been assigned to this issue.
Presumably you're going to create the appropriate RHEL & Fedora bugs to track this issue? It looks like Kees posted an updated patch yesterday; I haven't seen any replies to that submission yet. http://cygwin.com/ml/libc-alpha/2012-02/msg00328.html
This issue affects the version of the glibc package, as shipped with Red Hat Enterprise Linux 5 and 6. This issue affects the version of the glibc package, as shipped with Fedora release of 15 and 16. The child bugs for affected versions will follow shortly.
Created glibc tracking bugs for this issue Affects: fedora-all [bug 794797]
(Learned about this on LWN today.) (In reply to comment #3) > It looks like Kees posted an updated patch yesterday; I haven't seen any > replies to that submission yet. > > http://cygwin.com/ml/libc-alpha/2012-02/msg00328.html The easiest fix would have been to restrict "nargs" to NL_ARGMAX. http://www.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html#tag_13_23_03_07 $ cat /etc/redhat-release Red Hat Enterprise Linux Workstation release 6.2 (Santiago) $ getconf NL_ARGMAX 4096 I guess with the patch that went in an attacker could still force an allocation attempt of eg. 1.5 GB on the heap. I think it's plain unreasonable to allow that. 4096 numbered arguments should be enough for anyone (TM), including field width, precision, and "normal data" args.
Fix committed upstream in: http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=7c1f4834d398163d1ac8101e35e9c36fc3176e6e Followed by a correction patch that sets errno correctly in case of the failure: http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=fa0355175d60ccf610c98f2345504603d3b8ea57 Related discussion starts at: http://sourceware.org/ml/libc-alpha/2012-03/msg00053.html
Yea saw it this morning. The setting of errno is fairly minor; I've pulled that into our 6.3 tree and will pull it into our 5.9 tree shortly. I don't think it's worth respinning 5.8-z or 6.2-z just to pick up those two errno settings.
(In reply to comment #8) > The easiest fix would have been to restrict "nargs" to NL_ARGMAX. Bounced your proposal to libc-alpha: http://sourceware.org/ml/libc-alpha/2012-03/msg00101.html Upstream preference is to only limit by the available memory, rather than using any other arbitrary limit.
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2012:0393 https://rhn.redhat.com/errata/RHSA-2012-0393.html
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2012:0397 https://rhn.redhat.com/errata/RHSA-2012-0397.html
Already fixed in Fedora via: https://admin.fedoraproject.org/updates/FEDORA-2012-2144/glibc-2.14.1-6 https://admin.fedoraproject.org/updates/FEDORA-2012-2162/glibc-2.14.90-24.fc16.6 https://admin.fedoraproject.org/updates/FEDORA-2012-2123/glibc-2.15-23.fc17
This issue has been addressed in following products: RHEV-H, V2V and Agents for RHEL-5 Via RHSA-2012:0488 https://rhn.redhat.com/errata/RHSA-2012-0488.html
This issue has been addressed in following products: RHEV-H and Agents for RHEL-6 Via RHSA-2012:0531 https://rhn.redhat.com/errata/RHSA-2012-0531.html