taviso

Last week I discovered a bug that that caused an arithmetic operation used during allocation to overflow in ld.so, the dynamic loader. Red Hat (who have several core glibc people on staff) immediately disputed the bug was a security issue.

This isn't the first time they've done this, I reported a heap overflow in zlib in 2005 that Red Hat arbitrarily decided was not exploitable as the data was not controllable, and managed to convince several vendors this was the case. They were completely wrong, I even emailed them several testcases that demonstrated controllable data with the zlib they shipped at the time, but they conveniently ignored this.

So, why is Red Hat disputing it this time, here is an excellent analysis of the flaw by Jakub Jelinek.

http://www.cygwin.com/ml/libc-hacker/2007-07/msg00001.html

the problematic case is [...] where malloc returns != -1UL, but smaller than the expected size, either because of overflow (for cnt == 28), or because ld.so's _end was closer to end of virtual address space than the non-overflown size of the region. [...] In order to alter the stack, a lot of luck would be needed, such that ld.so's _end is exactly (1 << cnt) * 8 bytes below the stack page, otherwise it will reach some unmapped page before reaching the stack page and segfault. That's theoretically possible, but very unlikely. [...] So if ld.so's _end happend to be very high in the address space and exactly (1 << cnt) * 8 below stack page or mmap returned similar address (unlikely), it is possible to change the address where mempcpy returns to, but it likely won't be to a mapped space where code can be executed and if it will, the attacker doesn't have much control over where it will land and what will it do there. As ld.so is mostly uninitialized, the chances it successfully loads other libraries are very small and there are no sequences in ld.so which e.g. let you spawn shell.

(emphasis and snipping mine, see original for context)

I dont dispute Jakub's glibc expertise, I'm certain his analysis is correct, but I do dispute that if something requires luck, then it shouldn't count as a security issue. I'm certain this is exploitable, and I haven't given up working on this vulnerability yet (Not that Red Hat will ever admit they're wrong).

I also dispute "there are no sequences in ld.so which e.g. let you spawn shell.", spawning a shell isn't the only desirable action of an exploit, and I really doubt there are no code sequences anywhere that would be desirable for an attacker to execute as root (of course, you can always split instructions, or jump to data that happens to be executable).

Gentoo has issued an update as a precaution, as we're not willing to gamble with the security of our users.

If anyone is interested in helping on working on this vulnerability, feel free to contact me and I'd be happy to share my notes. I have made some progress, and would love to get a working PoC for this issue.