various applications dealing with binary files are vulnerable to a heap overflow, it's possible to integer overflow the argument to malloc by specifying a specific number of section headers that when multiplied with the size of the struct required to store the section headers, leading to a heap overflow.
I believe this issue to be exploitable.
The following packages are known to be vulnerable:
sys-devel/binutils (objdump, strings (!!!), nm, etc)
dev-libs/elfutils (eu-readelf, etc)
There are probably more, an example (harmless) binary that triggers this bug is attached.
Created attachment 57996 [details]
example malformed binary
add execstack/prelink to the list
sys-apps/less uses strings in lesspipe.sh, convincing someone a binary is a text file (eg, calling it README.TXT) and getting someone to run less on it could trigger this vulnerability.
try running less on the attached binary, then look at the console.
/usr/bin/lesspipe.sh: line 10: 15082 Segmentation fault (core dumped) strings "$F"
Only the first 78 bytes of the a.out matter. (head -c78 a.out)
gdb crashes here.
#0 0x081dbe78 in bfd_elf32_object_p (abfd=0x831e458) at elfcode.h:662
#1 0x081c856c in bfd_check_format_matches (abfd=0x831e458, format=bfd_object, matching=0x0) at format.c:228
#2 0x081c8324 in bfd_check_format (abfd=0x831e458, format=bfd_object) at format.c:91
#3 0x08079fd0 in exec_file_attach (filename=0xbfffe615 "a.out", from_tty=0x1) at exec.c:221
#4 0x0807e390 in do_captured_command (data=0xbfffe120) at top.c:554
#5 0x0807e2fc in do_catch_errors (uiout=0x831cdc8, data=0xbfffe0f8) at top.c:524
#6 0x0807e0a0 in catcher (func=0x807e2e0 <do_catch_errors>, func_uiout=0x831cdc8, func_args=0xbfffe0f8, func_val=0xbfffe104, func_caught=0xbfffe100, errstring=0x823e4c1 "", gdberrmsg=0x0, mask=0x6) at top.c:431
#7 0x0807e350 in catch_errors (func=0x807e36a <do_captured_command>, func_args=0xbfffe120, errstring=0x823e4c1 "", mask=0x6) at top.c:536
#8 0x0807e3dd in catch_command_errors (command=0x8079eae <exec_file_attach>, arg=0xbfffe615 "a.out", from_tty=0x1, mask=0x6) at top.c:574
#9 0x0807536d in captured_main (data=0xbfffe440) at main.c:645
#10 0x0807e2fc in do_catch_errors (uiout=0x82c8c80, data=0xbfffe3f8) at top.c:524
#11 0x0807e0a0 in catcher (func=0x807e2e0 <do_catch_errors>, func_uiout=0x82c8c80, func_args=0xbfffe3f8, func_val=0xbfffe404, func_caught=0xbfffe400, errstring=0x823a71a "", gdberrmsg=0x0, mask=0x6) at top.c:431
#12 0x0807e350 in catch_errors (func=0x80748e7 <captured_main>, func_args=0xbfffe440, errstring=0x823a71a "", mask=0x6) at top.c:536
#13 0x08075702 in gdb_main (args=0xbfffe440) at main.c:810
#14 0x080748a4 in main (argc=0x2, argv=0xbfffe4b4) at gdb.c:35
eu-readelf crashes here.
#0 0x40039490 in file_read_elf (fildes=0x805bb18, map_address=0x40016000, offset=0x0, maxsize=0x65, cmd=ELF_C_READ_MMAP, parent=0x0) at elf_begin.c:274
#1 0x400399dd in __libelf_read_mmaped_file (fildes=0x3, map_address=0x40016000, offset=0x0, maxsize=0x200, cmd=ELF_C_READ_MMAP, parent=0x0) at elf_begin.c:432
#2 0x40039ec8 in read_file (fildes=0x3, offset=0x0, maxsize=0x200, cmd=ELF_C_READ_MMAP, parent=0x0) at elf_begin.c:548
#3 0x4003a919 in elf_begin (fildes=0x3, cmd=ELF_C_READ_MMAP, ref=0x0) at elf_begin.c:1025
#4 0x08049ede in main (argc=0x3, argv=0xbfffe574) at readelf.c:208
All the elfutils die in file_read_elf()
Created attachment 58057 [details, diff]
patch for binutils provided by Sebastian Krahmer of suse.
app-editors/hteditor-0.8.0-r1 has a patch that corrects this issue from dragonheart.
hteditor upstream have fixed the bug in their cvs repository, ChangeLog entry:
app-editors/hteditor-0.8.0-r2 was committed by dragonheart and contains a fix for this issue and an additional fix from cvs to prevent a buffer overflow when parsing PE executables.
handling app-editors/hteditor stable marking on bug #91569
gdb-6.3-r3 patched up with suse bfd/elfcode patch.
(no arch has marked the .gdbinit sec bug former-r2 as stable)
gdb-6.0: -hppa ia64
gdb-6.3: ppc64 alpha hppa amd64 arm x86 sparc
gdb-6.3-r3: ~arm ~hppa ~x86 ~amd64 ~ppc ~alpha ~sparc ~ppc64 ~mips
added the patch by Sebastian to binutils, but solar pointed out it's not a complete fix ... still possible to crash bfd
Created attachment 58185 [details]
I don't use prelink or ES so somebody else will have to look into it further..
(It's non BFD based)
Anybody dev thats on the binutils-ml want to report this and a few more bfd based crashes?
sure i'll report it to binutils ... i wasnt sure if you were going to ;)
Created attachment 58471 [details, diff]
fix for crash on phdr == NULL
Created attachment 58472 [details]
phdr == NULL testcase
Created attachment 58473 [details, diff]
fix for crash on phdr or hdr == NULL
Created attachment 58474 [details]
hdr == NULL testcase
Created attachment 58482 [details, diff]
additional sanity checks
fix additional crashes identified by solar.
Using this as an audit tracker -> Component set to Auditing. Separate bugs have been opened for each of the affected software.
A patched elfutils crashes(other?) with the following 52 byte ELF.
binutils-188.8.131.52.2-r9 is now in portage patched
if i see no issues, i'll update the other binutil versions
upstream just posted another fix today heh
following versions of binutils have been added (only versions which were
actually KEYWORD-ed have been bumped)
note, note all of these are candidates for stable, i'm just listing what has a
revbump ... if i missed a version, tell me :p
Arches please mark your version stable.
Note: m68k does not have an arch alias and thus was not called.
Already marked stable by lu_zero.
stable on amd64
stable on ppc64
Stable on hppa
Keeping this bug for binutils... and marking the other one as dupe
*** Bug 91813 has been marked as a duplicate of this bug. ***
Stable on alpha + ia64.
binutils-184.108.40.206.2-r10 sparc stable.
binutils-220.127.116.11.2-r10.ebuild was marked stable by spanky..
mips, s390, sh please remember to mark stable.
binutils-18.104.22.168.2-r10 stable on mips.