Notes on the GHOST Bug

The recent GHOST bug discovered in glibc is a heap buffer overflow that could potentially lead to arbitrary code execution. I am interested to learn about this bug because I am working on heap buffer overflow defense. So I read the post written by Qualys Security Advisory, which really provides excellent explanation of it! [1]

This article just contains some of my notes when learning this bug. Hope they will also be helpful to others and please feel free to provide your comments.

(1) Why can't we detect this bug earlier?

It has been said that this bug existed since 2000. So an important question is why can't we detect it earlier? The article written by Qualys indicates that they found it through a manual code review. So probably the code has not received enough eyeballs previously.

On the other hand, I also think this bug is fairly easy to be detected by fuzzing. Because it is actually very easy to create test inputs and the oracle in this case. On the other hand, it is probably not easy to find the Heartbleed vulnerability through fuzzing, because both the test inputs and the oracle are hard to build.

I have wrote the following simple program that could trigger the vulnerability. We can think it as a very simple fuzzer.

https://github.com/movingname/Toys/blob/master/C/GHOST2.c

We can use the AddressSanitizer as the oracle. So I used clang + AddressSanitizer to compile it. Then when I ran it, AddressSanitizer indeed reports a heap buffer overflow.

I guess one could do a round of fuzzing for all this kind of functions in libraries. Maybe more bugs can be found?


(2) procmail exploit

The article [1] shows how we can exploit this bug in procmail using

/usr/bin/procmail 'VERBOSE=on' 'COMSAT=@...ython -c "print '0' * $((0x500-16*1-2*4-1-4))"` < /dev/null

However, this command has some omissions (the ... in the middle). Actually, one can run

/usr/bin/procmail 'VERBOSE=on' 'COMSAT=@'`python -c "print '0' * $((0x500-16*1-2*4-1-4))"` < /dev/null

to trigger the glibc detection.

In addition, the length of the input is important. Apparently it cannot be too small. But it also cannot be too large because procmail will detect the overflow. there is a tiny window that will trigger the overflow.



References:

[1] http://www.openwall.com/lists/oss-security/2015/01/27/9