Bug 1680660 (CVE-2019-9072)

Summary: CVE-2019-9072 binutils: excessive memory allocation in function setup_group in elf.c
Product: [Other] Security Response Reporter: Dhananjay Arunesh <darunesh>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED NOTABUG QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: abhgupta, aoliva, dbaker, dvlasenk, fweimer, jakub, jokerman, law, mprchlik, nickc, ohudlick, sthangav, trankin
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-03-18 21:12:31 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1680661    
Bug Blocks: 1680680    

Description Dhananjay Arunesh 2019-02-25 13:31:56 UTC
An issue was discovered in the Binary File Descriptor (BFD) library (aka libbfd), as distributed in GNU Binutils 2.32. It is an attempted excessive memory allocation in setup_group in elf.c.

Reference:
https://sourceware.org/bugzilla/show_bug.cgi?id=24232

Comment 1 Dhananjay Arunesh 2019-02-25 13:32:14 UTC
Created binutils tracking bugs for this issue:

Affects: fedora-all [bug 1680661]

Comment 4 Scott Gayou 2019-03-18 21:08:56 UTC
This does not appear to be an actual issue. Yes, ASAN warns that the allocation fails, but the binutils tool handles that case correctly.

Here's a Red Hat Enterprise Linux 7 valgrind run for grins:

```
==27914== Memcheck, a memory error detector
==27914== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==27914== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==27914== Command: objdump -x poc
==27914== 
objdump: poc: corrupt size field in group section header: 0x6072740080
objdump: poc: no valid group sections found
objdump: poc: no group info for section 
objdump: poc: Bad value
==27914== 
==27914== HEAP SUMMARY:
==27914==     in use at exit: 19,620 bytes in 10 blocks
==27914==   total heap usage: 72 allocs, 62 frees, 31,164 bytes allocated
==27914== 
==27914== LEAK SUMMARY:
==27914==    definitely lost: 0 bytes in 0 blocks
==27914==    indirectly lost: 0 bytes in 0 blocks
==27914==      possibly lost: 0 bytes in 0 blocks
==27914==    still reachable: 19,620 bytes in 10 blocks
==27914==         suppressed: 0 bytes in 0 blocks
==27914== Rerun with --leak-check=full to see details of leaked memory
==27914== 
==27914== For counts of detected and suppressed errors, rerun with: -v
==27914== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
```

Comment 5 Scott Gayou 2019-03-18 21:11:05 UTC
Red Hat Enterprise Linux 6 (objdump version 2.20.51.0.2-5.48.el6 20100205) is slightly different, but still looks to process the file "correctly" -- i.e., no memory corruption, no impact to confidentiality, integrity, or availability.

```
valgrind objdump -x poc
==27815== Memcheck, a memory error detector
==27815== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==27815== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==27815== Command: objdump -x poc
==27815== 
BFD: poc: Corrupt size field in group section header: 0x6072740080
objdump: poc: Bad value
==27815== 
==27815== HEAP SUMMARY:
==27815==     in use at exit: 0 bytes in 0 blocks
==27815==   total heap usage: 20 allocs, 20 frees, 123,610 bytes allocated
==27815== 
==27815== All heap blocks were freed -- no leaks are possible
==27815== 
==27815== For counts of detected and suppressed errors, rerun with: -v
==27815== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 6)
```