https://sourceware.org/bugzilla/show_bug.cgi?id=34727
Bug ID: 34727
Summary: od-xcoff: OOB reads in dump_xcoff32_loader/typchk
(unbounded .loader counts and offsets) via objdump -P
loader/typchk
Product: binutils
Version: 2.48 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: venkatchallaceh at gmail dot com
Target Milestone: ---
Created attachment 17068
--> https://sourceware.org/bugzilla/attachment.cgi?id=17068&action=edit
Patch: bound the .loader and .typchk dumpers against the section size (git
format-patch)
binutils/od-xcoff.c's loader and type-check dumpers have out-of-bounds heap
reads reachable via "objdump -P loader <crafted.xcoff>" and "objdump -P typchk
<crafted.xcoff>".
dump_xcoff32_loader() reads the .loader section into a heap buffer of exactly
the section size (ldr_data = xmalloc (size)), checks only that the size is at
least the loader header, and then reads several file-controlled fields from the
header (l_nsyms/ndsyms, l_nreloc/ndrel, l_nimpid/nimpid, l_impoff/impoff,
l_stoff/stoff, l_stlen/stlen). None of these counts or offsets is bounded
against the section size before it is used to walk the buffer:
- "for (i = 0; i < ndsyms; i++, ldsym++)" walks ldsym (one external_ldsym
each) past ldr_data+size;
- "printf (\"%s\", ldr_data + stoff + off)" prints a name with stoff
unbounded;
- the reloc loop base "ldr_data + sizeof(*lhdr) + ndsyms*sizeof(*ldsym)" and
"for (i = 0; i < ndrel; ...)" walk past the buffer;
- the import-files loop "p = ldr_data + impoff; for (i = 0; i < nimpid; i++)
{ strlen (p); ... }" runs strlen off the end of the buffer.
A tiny but otherwise valid .loader section (size == loader-header size) with
e.g. l_nsyms = 0xffffffff triggers the symbol-loop OOB immediately; the bytes
are printed to the operator's terminal (information leak).
dump_xcoff32_typchk() reads a 2-byte length "len" at data+i and then dumps up
to "len" bytes (data[i+j]) with no check that i+2 or i+len stay within the
section size.
Reachability: "objdump -P loader" / "objdump -P typchk" are standard objdump
invocations; the XCOFF targets and od-xcoff dumper are built into any
--enable-targets=all binutils. This mirrors the od-macho prebound_dylib issue
(bug 34725); the existing XCOFF CVEs are all in bfd (coff-rs6000.c /
xcofflink.c), not this dumper.
Fix (attached): bound every file-controlled count and offset against the
section size using overflow-safe subtraction/division, cap the symbol-name
print, bound the import-file string scans with strnlen, and bound each typchk
read against the section size. The same patch was/will also be sent to the
binutils mailing list.
AI assistance was used in preparing this report and patch; both were reviewed,
built (objdump builds clean), and verified by a human.
--
You are receiving this mail because:
You are on the CC list for the bug.
