Qualys Inc. issued an interesting security advisory regarding a 10-year old vulnerability in Sudo. The well-written advisory is informative on the vulnerability itself providing a concise analysis of the vulnerable code causing the heap overflow. Additionally it may serve as a lesson on ASLR-aware exploitation of a heap buffer overflow.
I intended to write a post to document my methods and to share my lessons learned from reproducing and expanding the exploit by Qualys. I Especially wanted to look into the failed method number 1, a libc buffer overflow a.k.a. "RationalLove", from the "Baron Samedit" advisory, and try to get it to work. This explains the name of this article. But then strange things happened... Even if this is the (somewhat special) first post, it has to stay incomplete due to ongoing investigation. But for now, let's follow the initial plan:
Qualys is known for their meticulous work analyzing and exploiting vulnerabilities reliably. Qualys describes four attempts to gain full control. Only three of them were successful and none of those were simple.
The main obstacles for heap overflow exploitation to gain control are the various counter measures in place to prevent corrupted data from affecting the program flow. Therefore, modern operating systems, compilers, libraries, and heap managment work together to avoid simple, deterministic exploitation of buffer overflows by making the memory layout non-deterministic. Additionally, heap memory chunk structures are designed to ease detection of overflows. The program will terminate as soon as a memory corruption is detected. Often that would turn the overflow into a mere DoS-condition. Because of this any exploitation would have to carefully modify the data to alter the control flow and finally take full control before the program aborts or exits. Due to ASLR, overwriting pointers usually has to be done without knowing what new value to use to make the pointer point to suitable data.
Consequently Qualys' pure in-memory function pointer overwrite exploit (method 1 in their advisory) that is hampered by those protective mechanisms has only a 1:4096 chance of success, otherwise the program crashes. Crashing a program thousands of times before privilege escalation might go unnoticed on unmaintained machines. In proper IT environments the attempts will put most intrusion detection systems to high alert. Ideally a good exploit will never crash the program.
The common denominator of all the stable methods, but also the unsuccessful attempt reported in Qualys' advisory is that they leverage modification of strings being used later on to create filenames for reading or writing. Getting a hold of any of those strings shifts the attack point from the ASLR-protected, everchanging memory layout to a deterministic, predictable file system access. Because file systems are designed to always serve the same data for the same address (path), nothing can be done to prevent the attacker from accessing exactly the data they want.
As described above, there is a reason to use the file system as proxy for code execution. I began by analyzing where and how Sudo processes file system related strings on the heap. Because Qualys worked hard to come up with their findings, I did not expect new results soon. Surprisingly, quite immediately after configuring the first automated analysis run, some unexpected results were found... (read more in part 2).
While still learning, the following lessons were the most important for me today:
Try Replicating Results: As in science replicating or improving other people's work is often deemed inferior. True heroes want to lead (even when it is dreadfully inefficient) instead of following in other's footsteps. Therefore by quickly putting the as-I-would-have expected-it tag on others' findings and then ignoring these may make you miss great opportunities to learn, cooperate with other researchers and even extend the current published knowledge.
Verify Your Assumptions: With growing knowledge we are tempted to believe that we understand a topic fully. But that puts us at risk of missing relevant information because we thought we already knew even without checking. In worst case we will be blind to the obvious because we do not question things any more. Therefore, strangely, my lack of knowledge about the internals of Sudo allowed me to gain knowledge about another Sudo vulnerability by testing assumptions and analyzing portions of code that would not have been of relevance to those already knowing that there is nothing to be found in that direction.
Complexity Kills: Digging into the Sudo code, stack traces and execution flows showed again that even with all the information in plain sight (white box testing, open source...) that it is really hard to spot complex program flow bugs. While each function by itself is "binary" secure (no overflows, double frees...) the call order of those functions is not clear (affected by configuration parameters, plugins...) so that in the end the functions will produce "binary correct" data but for a wrong reason. Hence in theory complex tools like Sudo allow finegrained permission control. But due to complexity the tool itself creates a huge attack surface.
Hardening Helps: Analyzing the reason why in my testing environment the Sudo heap buffer overflow exploitation was categories easier than on the machines used by Qualys showed that the failure of another unrelated hardening feature turned a hard-to-exploit heap overflow into a trivial one. Thus the hardening feature really helped to buy time after disclosure of the vulnerability till circulation of first exploits in the wild. Time that hopefully was used for patching.
Notes:
Comments are welcome, but there is no forum system im place yet. If there is something important to be added to this page, please send it as e-mail. Legal: Appropriate comments will be published, there is no right for you to get them published, use a "Nick:" entry in your comment otherwise for attribution "Anonymous" is used, comment mails are deleted after processing (GDPR), IPR rights for your comment stay with you except that the content may be used to correct or improve the page while referencing to your comment as source of the change, comment data is not submitted to third parties. Phuuu, inhale!