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.
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).
The CVE identifier of CVE-2012-3509 has been assigned to this issue.
Upstream bug report: [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54411 Proposed patch: [2] http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01986.html References: [3] https://bugzilla.novell.com/show_bug.cgi?id=776968 [4] http://www.openwall.com/lists/oss-security/2012/08/29/3
Created attachment 614014 [details] patch florian checked in
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.
Created gdb tracking bugs for this issue Affects: fedora-all [bug 860769]
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.
(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
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.
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.
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
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?
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.
Suits me, I'll strip the unused source code from these packages in the %prep phase
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.
He's only proposing that for mingw-headers, mingw-crt and mingw-w64-tools, I believe.
That's correct, and I'm also one of the primary maintainers of those packages
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
Excellent, thank you!
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
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?
(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.
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).
(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).
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.
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.
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.
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.
Direct link to upstream patch: http://gcc.gnu.org/viewcvs?view=revision&revision=191413