Memory corruption in ld.so
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
eglibc (Ubuntu) |
Fix Released
|
Low
|
Unassigned | ||
Dapper |
Invalid
|
Undecided
|
Unassigned | ||
Hardy |
Invalid
|
Undecided
|
Unassigned | ||
Intrepid |
Invalid
|
Undecided
|
Unassigned | ||
Jaunty |
Invalid
|
Undecided
|
Unassigned | ||
Karmic |
Fix Released
|
Low
|
Unassigned | ||
Lucid |
Fix Released
|
Low
|
Unassigned | ||
glibc (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
Dapper |
Fix Released
|
Low
|
Unassigned | ||
Hardy |
Fix Released
|
Low
|
Unassigned | ||
Intrepid |
Won't Fix
|
Low
|
Unassigned | ||
Jaunty |
Fix Released
|
Low
|
Unassigned | ||
Karmic |
Invalid
|
Undecided
|
Unassigned | ||
Lucid |
Invalid
|
Undecided
|
Unassigned |
Bug Description
I have discovered a memory corruption vulnerability in ld.so. When processing maliciously crafted ELF binaries using ld.so, regardless of whether execution of those binaries is intended (for example, I tested using the "--verify" flag, which should not lead to any code execution), arbitrary code execution can be achieved.
The relevant code is in elf/dynamic-link.h, in the elf_get_
I have confirmed that this can lead to arbitrary code execution. For simplicity, I tested on Ubuntu Jaunty 9.04 on a 32-bit x86 machine, with ASLR disabled (/proc/
/lib/ld-2.9.so --verify ./test
The exploit overwrites a return address on the stack, pointing it into the dyn struct. This struct contains first-stage shellcode that jumps execution into the .data segment and spawns a shell. This is not a robust exploit - it is mitigated by NX support on later distributions (since code execution is taking place in .data), and ASLR would make it impossible to reliably overwrite a return address on the stack. It may not even work reliably on other machines - since exact stack offsets are used, it may be subject to changes in environment variables, etc. However, I'm sure that a more talented exploit writer could produce a more robust exploit, and my example should prove the point that this is a code execution issue. If the exploit does not spawn a shell, I would expect it to cause a segfault.
This problem can be mitigated by defining Elf32_Sword as an unsigned int, to be consistent with its documentation. If this may have other unintended effects, then more careful checking of array bounds in the vulnerable function should be done, to prevent writing to arbitrary memory locations.
Changed in glibc (Ubuntu): | |
status: | New → Triaged |
importance: | Undecided → Low |
Changed in glibc (Ubuntu Karmic): | |
status: | New → Invalid |
Changed in glibc (Ubuntu Lucid): | |
status: | Triaged → Invalid |
importance: | Low → Undecided |
Changed in glibc (Ubuntu Jaunty): | |
importance: | Undecided → Low |
Changed in glibc (Ubuntu Intrepid): | |
importance: | Undecided → Low |
Changed in glibc (Ubuntu Hardy): | |
importance: | Undecided → Low |
Changed in glibc (Ubuntu Dapper): | |
importance: | Undecided → Low |
Changed in eglibc (Ubuntu Jaunty): | |
status: | New → Invalid |
Changed in eglibc (Ubuntu Intrepid): | |
status: | New → Invalid |
Changed in eglibc (Ubuntu Hardy): | |
status: | New → Invalid |
Changed in eglibc (Ubuntu Dapper): | |
status: | New → Invalid |
Changed in glibc (Ubuntu Dapper): | |
status: | New → Triaged |
Changed in glibc (Ubuntu Hardy): | |
status: | New → Triaged |
Changed in glibc (Ubuntu Intrepid): | |
status: | New → Triaged |
Changed in glibc (Ubuntu Jaunty): | |
status: | New → Triaged |
Changed in eglibc (Ubuntu Lucid): | |
status: | New → Triaged |
importance: | Undecided → Low |
Changed in eglibc (Ubuntu Karmic): | |
status: | New → Triaged |
importance: | Undecided → Low |
visibility: | private → public |
Changed in glibc (Ubuntu Dapper): | |
status: | Triaged → Fix Released |
Changed in glibc (Ubuntu Intrepid): | |
status: | Triaged → Won't Fix |
Changed in eglibc (Ubuntu): | |
assignee: | nobody → dave weston (davidweezer) |
status: | Triaged → Fix Released |
Changed in eglibc (Ubuntu): | |
assignee: | dave weston (davidweezer) → nobody |
status: | Fix Released → Triaged |
tags: | added: patch |
I haven't dug fully into this yet, but it seems slightly related to similar issues with ld in general?
http:// www.catonmat. net/blog/ ldd-arbitrary- code-execution/