Bug 794766 (CVE-2012-0864) - CVE-2012-0864 glibc: FORTIFY_SOURCE format string protection bypass via "nargs" integer overflow
Summary: CVE-2012-0864 glibc: FORTIFY_SOURCE format string protection bypass via "narg...
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2012-0864
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
: 794763 (view as bug list)
Depends On: 794797 794813 794814 794815 794817
Blocks: 790425
TreeView+ depends on / blocked
 
Reported: 2012-02-17 15:11 UTC by Stefan Cornelius
Modified: 2019-09-29 12:50 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-03-20 09:16:57 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2012:0393 normal SHIPPED_LIVE Moderate: glibc security and bug fix update 2012-03-15 20:37:29 UTC
Red Hat Product Errata RHSA-2012:0397 normal SHIPPED_LIVE Moderate: glibc security update 2012-03-20 01:57:06 UTC
Red Hat Product Errata RHSA-2012:0488 normal SHIPPED_LIVE Important: rhev-hypervisor5 security and bug fix update 2012-04-17 21:51:57 UTC
Red Hat Product Errata RHSA-2012:0531 normal SHIPPED_LIVE Important: rhev-hypervisor6 security and bug fix update 2012-04-30 21:13:45 UTC

Description Stefan Cornelius 2012-02-17 15:11:58 UTC
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

Comment 1 Stefan Cornelius 2012-02-17 15:48:02 UTC
*** Bug 794763 has been marked as a duplicate of this bug. ***

Comment 2 Stefan Cornelius 2012-02-17 15:52:56 UTC
A CVE identifier of CVE-2012-0864 has been assigned to this issue.

Comment 3 Jeff Law 2012-02-17 16:31:49 UTC
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

Comment 4 Stefan Cornelius 2012-02-17 16:47:33 UTC
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.

Comment 5 Stefan Cornelius 2012-02-17 16:57:32 UTC
Created glibc tracking bugs for this issue

Affects: fedora-all [bug 794797]

Comment 8 Laszlo Ersek 2012-03-01 11:44:32 UTC
(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.

Comment 9 Tomas Hoger 2012-03-05 09:53:17 UTC
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

Comment 10 Jeff Law 2012-03-05 17:02:28 UTC
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.

Comment 12 Tomas Hoger 2012-03-06 11:01:50 UTC
(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.

Comment 13 errata-xmlrpc 2012-03-15 16:38:06 UTC
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

Comment 14 errata-xmlrpc 2012-03-19 21:57:41 UTC
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

Comment 16 errata-xmlrpc 2012-04-17 17:54:01 UTC
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

Comment 17 errata-xmlrpc 2012-04-30 17:16:30 UTC
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


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