Bug 849693 - (CVE-2012-3509) CVE-2012-3509 libiberty: integer overflow, leading to heap-buffer overflow by processing certain file headers via bfd binary
CVE-2012-3509 libiberty: integer overflow, leading to heap-buffer overflow by...
Status: NEW
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,public=20120829,repor...
: Security
Depends On: 877017 860769 877012 877013 877014 877018 1059360 1059361 1059362 1059363 1059364 1059365 1059367 1059368 1059370 1059373 1059375 1059378 1059379 1059390 1059396
Blocks: 849705
  Show dependency treegraph
 
Reported: 2012-08-20 11:38 EDT by Jan Lieskovsky
Modified: 2016-03-04 06:16 EST (History)
22 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
patch florian checked in (1.71 KB, patch)
2012-09-18 09:09 EDT, Jeff Law
no flags Details | Diff

  None (edit)
Description Jan Lieskovsky 2012-08-20 11:38:03 EDT
An integer overflow, leading to heap-based buffer overflow flaw was found in the way libiberty library, a collection of subroutines used by various GNU programs, performed space allocation from an objalloc structure. A remote attacker could provide a binary file which specially-crafted header that, when processed by some of the bfd binaries (nm, objcopy, objdump etc.) would lead to that bfd executable crash or, potentially, arbitrary code execution with the privileges of the user running the bfd binary.
Comment 2 Jan Kratochvil 2012-08-20 11:46:59 EDT
Is there a remote code execution possibility?  (I do not think so.)

If we should fix all DoS (crash) problems it opens a whole new class of bugs (such as gdb/dwarf2read.c is full of them).
Comment 6 Jan Lieskovsky 2012-08-23 12:51:03 EDT
The CVE identifier of CVE-2012-3509 has been assigned to this issue.
Comment 10 Jeff Law 2012-09-18 09:09:05 EDT
Created attachment 614014 [details]
patch florian checked in
Comment 13 Jan Lieskovsky 2012-09-26 12:40:36 EDT
The versions of gdb package, as shipped with Red Hat Enterprise Linux 5 and 6 are affected by the original libiberty integer overflow flaw. But due the way of subsequent gdb processing of that previously insufficiently pre-allocated buffer the impact of this issue in gdb package for Red Hat Enterprise Linux 5 and 6 is limited to be crash only. The buffer is immediately zeroed, effectively making the attempt to write invalid data it to be restricted to possibility to write zeroes only, mitigating the consequence to gdb executable crash.

--

The versions of gdb package, as shipped with Fedora release of 16 and 17 are affected by the original libiberty integer overflow flaw. But due the way of subsequent gdb processing of that previously insufficiently pre-allocated buffer the impact of this issue in gdb package for Fedora release of 16 and 17 is limited to be crash only. The buffer is immediately zeroed, effectively making the attempt to write invalid data it to be restricted to possibility to write zeroes only, mitigating the consequence to gdb executable crash.


Red Hat Security Response Team does not consider user-assisted crash of end-user application, such as gdb, to be a security flaw.
Comment 14 Jan Lieskovsky 2012-09-26 12:42:17 EDT
Created gdb tracking bugs for this issue

Affects: fedora-all [bug 860769]
Comment 15 Toshio Kuratomi 2012-09-26 13:31:06 EDT
libiberty is one of the libraries that have been granted an exception to be bundled by the FPC (actually, the exception was granted by FESCo in the period during which FESCo had that responsibility).  Therefore, this affects all packages that bundle libiberty as well.

According to the Guidelines, packages that bundle libiberty are supposed to have a virtual Provides: bundled(libiberty)  However, repoquery only mentions one package:

$ repoquery -q --whatprovides 'bundled(libiberty)'
insight-0:7.4.50-1.20120403cvs.fc16.x86_64

When libiberty was granted an exception by FESCo in the F13 time frame, an audit of the package set by ajax found 24 packages that bundled libiberty:
  https://fedorahosted.org/fesco/ticket/370#comment:13

So someone's going to have to re-audit the packageset, identify the packages that bundle libiberty, update them, and also add the Provides: bundled(libiberty) so that this is easier the next time around.
Comment 16 Jan Kratochvil 2012-09-26 13:45:28 EDT
(In reply to comment #15)
> However, repoquery only mentions one package:
> $ repoquery -q --whatprovides 'bundled(libiberty)'
> insight-0:7.4.50-1.20120403cvs.fc16.x86_64

Since F-17 also:
gdb-0:7.4.50.20120120-42.fc17.x86_64
Comment 17 Toshio Ernie Kuratomi 2012-10-03 12:15:57 EDT
If someone is already working on auditing the packageset please speak up so I know.

Otherwise I'm going to open a ticket with fesco to see about getting someone to work on this (note that fesco doesn't actually have any directable developer resources -- they can just put out a call for volunteers or one of the already overworked fesco members can volunteer themselves).  If we're lucky, ajax (no longer a fesco member) may have his old information on libiberty usage still available.
Comment 18 Adam Jackson 2012-10-10 14:31:00 EDT
For the record: no, I don't, but it's worth re-auditing anyway, as there's no telling how many more places GNU copied this around instead of hardening up and making a real shared library already.
Comment 19 Jon Ciesla 2012-10-16 12:13:46 EDT
List of libiberty bundlers, now with Provides: bundled(libiberty) unless FTBFS.

arm-gp2x-linux-binutils
arm-gp2x-linux-gcc
avr-binutils
avr-gcc
avr-gdb
binutils
compat-gcc-32  FTBFS
compat-gcc-34  FTBFS
cross-binutils
cross-gcc
gcc
gccxml
gdb
ghdl
gputils
insight
mingw-binutils
mingw-crt
mingw-gcc
mingw-gdb
mingw-headers
mingw-w64-tools
mono-debugger
msp430-binutils
msp430-gcc
nesc
sdcc           FTBFS
sh-elf-binutils
Comment 20 Erik van Pienbroek 2012-10-16 13:43:00 EDT
Jon,

I noticed you added the provides tag to various mingw packages. For mingw-binutils, mingw-gcc and mingw-gdb I think these are correct (as their native counterparts also use libiberty). However for mingw-headers, mingw-crt and mingw-w64-tools I think these are false positives. The source tarball of these packages indeed does include the source code for libiberty, but this code isn't used when building these packages. Is the provides tag really desired for those packages?
Comment 21 Jon Ciesla 2012-10-16 13:46:13 EDT
I'm of the opinion that if you rm -rf libiberty in setup, you can remove the provides.  We really want to be 100% sure it's not affected.
Comment 22 Erik van Pienbroek 2012-10-16 13:51:10 EDT
Suits me, I'll strip the unused source code from these packages in the %prep phase
Comment 23 Jeff Law 2012-10-16 13:54:01 EDT
You're not going to get as far as you might think.  gcc, binutils and gdb rely heavily on libiberty and often rely on the newest bits in those libraries.  What I'm saying is that those tools are in effect bound to the libiberty sources that are included in their releases.

Before going down that path I strongly suggest you discuss it with the appropriate package maintainers.
Comment 24 Jon Ciesla 2012-10-16 13:57:15 EDT
He's only proposing that for mingw-headers, mingw-crt and mingw-w64-tools, I believe.
Comment 25 Erik van Pienbroek 2012-10-16 14:18:42 EDT
That's correct, and I'm also one of the primary maintainers of those packages
Comment 26 Erik van Pienbroek 2012-10-16 15:13:37 EDT
Okay, the packages mingw-headers and mingw-crt now use a different source tarball which doesn't contain libiberty (and other unneeded files) any more. For mingw-w64-tools I'm currently waiting on an upstream developer to verify something, but once that's arranged I'll apply the change in that package too
Comment 27 Jon Ciesla 2012-10-16 15:18:00 EDT
Excellent, thank you!
Comment 28 Toshio Ernie Kuratomi 2012-10-30 13:08:45 EDT
Note: According to the fesco ticket[1]_, fesco thought it might be more appropriate for the security team to open bugs for the affected packages than fsco since the security team might have tooling to create an track the bugs.

I see that some of the other packages were added to the whiteboard for this bug and some of the other package maintainers are CC'd but not all of them. (for instance, mono-debugger owner: chkr)

I'm just making sure that the fesco request shows up here so that it doesn't fall through the cracks.

[1]_: https://fedorahosted.org/fesco/ticket/956#comment:19
Comment 29 Vincent Danen 2012-10-31 17:40:07 EDT
I've done some additional poking around on this.  In Fedora 17, I've found the following packages which contain libiberty/objalloc.c:

arm-gp2x-linux-binutils-2.16.1-11.fc17
arm-gp2x-linux-gcc-4.1.2-13.fc17
avr-binutils-2.20-3.fc17
avr-gcc-4.6.3-1.fc17
avr-gdb-7.1-4.fc17
binutils-2.22.52.0.1-10.fc17
CableSwig-3.20.0-6.fc17
compat-gcc-296-2.96-144
compat-gcc-32-3.2.3-68.3
compat-gcc-34-3.4.6-24.fc17
cross-gcc-4.7.1-0.1.20120606.fc17
gcc-4.7.2-2.fc17
gccxml-0.9.0-0.12.20120309.fc17
gdb-7.4.50.20120120-50.fc17
ghdl-0.29-2.143svn.6.fc17
insight-7.4.50-1.20120403cvs.fc17
mingw-binutils-2.22.52-4.fc17
mingw-crt-2.0.999-0.6.trunk.20120601.fc17
mingw-crt-2.0.999-0.6.trunk.20120601.fc17
mingw-gcc-4.7.0-2.fc17
mingw-gdb-7.4.50.20120603-1.fc17
mingw-headers-2.0.999-0.7.trunk.20120601.fc17
mingw-headers-2.0.999-0.7.trunk.20120601.fc17
mingw-w64-tools-2.0.999-0.2.trunk.20120124.fc17
mingw-w64-tools-2.0.999-0.2.trunk.20120124.fc17
mono-debugger-2.10-3.fc17
msp430-binutils-2.19.1-4.fc17
msp430-gcc-3.2.3-6.20100805cvs.fc17
nesc-1.3.4-1.fc17
sh-elf-binutils-2.21-3.fc17

Obviously not all of them compile in or use the affected function.  The following packages actually export the _objalloc_alloc symbol (this is incomplete as my tool doesn't have Fedora 17 imported, so this is from Fedora 16):

binutils-2.21.53.0.1-6.fc16 (binutils): _objalloc_alloc in /usr/lib/libbfd-2.21.53.0.1-6.fc16.so
crash-6.0.2-1.fc16 (crash): _objalloc_alloc in /usr/bin/crash
gdb-7.3.50.20110722-10.fc16 (gdb): _objalloc_alloc in /usr/bin/gdb
insight-6.8.1-4.fc15 (insight): _objalloc_alloc in /usr/bin/insight
lush-1.2.1-6.fc12 (lush): _objalloc_alloc in /usr/bin/lush
mono-debugger-2.10-1.fc16 (mono-debugger): _objalloc_alloc in /usr/lib/libmonodebuggerserver.so.0.0.0
mutrace-0.2-2.fc15 (mutrace): _objalloc_alloc in /usr/lib/libmutrace-backtrace-symbols.so

Based on prior discussion, it does not seem that gcc is affected by this, and the above backs it up unless gcc is hiding the symbols (or my tool is wrong).

It looks as though lush isn't in Fedora 17 so could be ignored, but the immediate suspects are gdb, binutils, crash, insight, mono-debugger, and mutrace.  I don't know about, for instance, avr-gdb as it doesn't seem to export the symbol, but I also don't know if that really means anything (not sure what avr binaries are or what "remote debugging is", based on the rpm description).

If nothing else, this is a list to work off of, at least initially.

I'm hesitant to file tracking bugs for these, however, because a tracking bug was filed for gdb a month ago for Fedora, and nothing has been done with it that I can see.  Is there a problem with the patch, or some other reason for not getting the fix into gdb?
Comment 30 Jan Kratochvil 2012-11-15 14:49:04 EST
(In reply to comment #29)
> The following packages actually export the _objalloc_alloc symbol

This is incomplete as _objalloc_alloc does not have to be exported but it still can be used inside the binary.

Package 'gdb' exports its very every symbol but this is a current bug to be fixed.  It is caused due to its linkage with Python:
  -Xlinker -export-dynamic

avr-gdb does not link with Python so it does not wasterfully export everything.
Therefore to very avr-gdb one has to verify _objalloc_alloc presence by:

# yum install avr-gdb-debuginfo
$ nm /usr/lib/debug/usr/bin/avr-gdb.debug | grep -w _objalloc_alloc
00000000005d85c0 T _objalloc_alloc

So avr-gdb and probably some other packages should be also listed as affected.
Comment 31 Jan Kratochvil 2012-11-16 03:16:32 EST
Jan,
is this bug therefore an "arbitrary code execution" exploitable or not?

IMO it is not, therefore it is a normal uninteresting crasher bug which has been fixed upstream now and which is IMO not even worth a backport.  There are many such uninteresting invalid-input crasher bugs in GNU toolchain (see Comment 2).
Comment 33 Jan Lieskovsky 2012-11-16 04:49:59 EST
(In reply to comment #31)

Hi Jan,

> Jan,
> is this bug therefore an "arbitrary code execution" exploitable or not?

Depends on the way how you are asking:
--------------------------------------
1) If you are asking generally if CVE-2012-3509 flaw can be used for arbitrary code execution (an adversary to reach code execution under the privileges of the victim, when the victim inspects provided file remotely), then the reply would be yes. The CVE-2012-3509 flaw is believed to be able to cause arbitrary code execution. To actually reach this it would not be a trivial task though.

2) If you are asking if gdb packages (since embedding libiberty code) are prone to arbitrary code execution, then the reply would be no. The actual exploitation depends on the 'code around' processing result of bfd_alloc2() / _objalloc_alloc and from what I can tell so far for gdb case, the resulting buffer is under-allocated, but the subsequent routine is just zero-ying its content at:

  #2  setup_group (newsect=0x29a9bf0, hdr=0x29b2690, abfd=0x297a960) at ../../bfd/elf.c:607

routine, so explicitly for gdb this could not allow arbitrary code execution.

> 
> IMO it is not, therefore it is a normal uninteresting crasher bug which has
> been fixed upstream now and which is IMO not even worth a backport.  There
> are many such uninteresting invalid-input crasher bugs in GNU toolchain (see
> Comment 2).

See above. If we are talking about gdb case here, then yes, I agree. But for the rest of possibly affected packages the potential impact still needs to be investigated (to either confirm the danger or disprove it like in gdb case).
Comment 34 Jan Lieskovsky 2012-11-16 05:42:15 EST
Statement:

The versions of the gdb package, as shipped with Red Hat Enterprise Linux 5 and 6 are vulnerable to the original libiberty integer overflow flaw. But due the way of subsequent processing of the previously insufficiently pre-allocated libiberty buffer within gdb code, the impact of this issue is limited to crash only. Red Hat Security Response Team does not consider crash of end-user application, such as gdb, to be a security flaw.
Comment 35 Fedora Update System 2012-11-23 02:25:36 EST
insight-7.4.50-4.20120403cvs.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 36 Fedora Update System 2012-11-23 22:31:45 EST
insight-7.4.50-4.20120403cvs.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 37 Fedora Update System 2012-11-23 22:33:43 EST
insight-7.4.50-4.20120403cvs.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 38 Jan Lieskovsky 2013-03-06 06:40:45 EST
Direct link to upstream patch:
  http://gcc.gnu.org/viewcvs?view=revision&revision=191413

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