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

Inflation and StackOverflow.com

(v0.1)

I really enjoy asking and answering questions on the StackOverflow.com, which has some exciting features. For example, it is mainly managed by the community, not the admin. So users on StackOverflow.com not only contributes information (Web 2.0), but also contributes "computation" (Web 3.0?). Another feature is the scoring system. A user can get scores based on votes of questions and answers she posts. This is a quite good incentive for users to offer there knowledge, because the score reflects one's progress and ability, and can be used in job interview. This second feature separates StackOverflow.com from traditional mail list based Q & A.


However, this reward mechanism also comes with an issue which I call it the disadvantage of late members. That is, it is more difficult for a late member to get the same amount of score than an early member. This is mainly because early questions are in general more important yet easier to answer than late questions. For example, user X asks how to sort a dictionary in Python. User Y easily answers this question. Since this question is quite common for new Python users, we can expect that many user will find this answer and give it a vote up. Y thus earns high score simply through a simple answer. Now after one year, Z enters StackOverflow.com. Z is much more knowledgeable in Python than Y, however, there are not such easy and rewarding questions for Z now. So Z's score might never go beyond Y's.

This issue could hurt the participation of such sites. New comers could lack strong incentive to make contributions, because they can hardly find questions to answer, and they cannot catch up with the early members anyway.

We can think about how to address this issue. I propose two simple ideas here. The first idea is to reduce the score of early members overtime. However, reducing one's "possession" sounds bad and might hurt the early members. A slightly different idea is to introduce inflation. That is, the Q & A site should increase the score for a vote up overtime, thus giving more scores to new members. Maybe the inflation in economy also serves similar purpose. After early some early people have accumulated a large amount of wealth, it would be hard for late people to catch up, because the rich people can have better return simply through safe investments such as government bond. Inflation, in some degree, could alleviate this issue.

Actually, the solution used by StackOverflow.com now is to have a recent ranking (e.g. in past year) together with overall ranking. The recent ranking would be a fairer play ground for everybody. However, the recent ranking is not as stable as the overall ranking, so I think the inflation idea still make sense. Of course, StackOverflow.com can complement the recent ranking with permanent badges (e.g. Top 1 in one month badge).

A related article：

Why I no longer contribute to Stackoverflow
http://michael.richter.name/blogs/why-i-no-longer-contribute-to-stackoverflow/