Let's get topical for a bit. I haven't posted for a while and I have quite a few things to talk about, but a paper from this month's Black Hat security conference in Las Vegas made quite a buzz and caught many people's attention, including mine. As it was posted on OSNews and Slashdot as a method to completely circumvent Vista's security, it was only natural that people loved it.
My first reaction to such news is to trust the text and distrust the title. One would hope that computer people would know to be less affected by sensationalist headlines, but it seems that the higher skepticism is counterbalanced by the decreased attention span.
The paper is written by established security experts and is a little bit technical (not too bad though), so I thought I would talk about each section of it and explain in simple terms what the measure is, what went wrong, whose fault it is, whether you should lose sleep over it and what you can do to decrease your risk.
One thing to note that should actually be obvious: The mentioned exploits are NOT directly applicable to a Windows machine. They mean that if a bug is found in a program, and that bug allows remote code execution, the attacker has a way to avoid these measures which try to detect and prevent bug exploitation.
For the full deal and accuracy, read the paper itself:
Bypassing Browser Memory Protections - Alexander Sotirov , Mark Dowd
GS (stack guarding)
The Measure: The Visual C++ compiler can use a 'stack cookie' to make sure that a stack buffer overflow does not corrupt the return address of the function. This is a common attack vector, and it means that the attacker can set his own memory address for the program to jump to when the current function exits. With this measure, if the overflow occurs, the cookie will also be corrupted , and as soon as the cookie validation function realizes that, execution halts and the attack is prevented.
The Problems: The stack cookie check can have a very significant performance cost. To reduce this, the Visual C++ compiler checks for conditions where an overflow would be 'impossible', and in those conditions, refrains from adding the check to the function.
The first problem stems from that: these conditions are flawed, and there are ways to cause an overflow in some functions that get away with not having a check.
The second problem is that the aforementioned cookie validation is not run when an exception occurs, so an overflow can replace the exception handler record with another value, cause an exception, and have the attacker-provided handler executed.
Lesson: The blame for this one would go to the compiler team, but the biggest problem with compiler-provided security measures such as this one is that flaws are almost certainly discovered too late for a fix to be effective. Thousands of binaries have already been compiled using this feature (including most Microsoft programs), which means that all of them are suspect until the compiler is fixed and new versions of every single one of the vulnerable binaries are redistributed as a patch.
Impact: It's hard to tell, at least from my perspective, how important this hole is. The possibility of functions that are vulnerable to stack buffer overflows has been proven, but their numbers in Windows and other programs are up to more experienced security analysts to find.
What you can do: If you are a Windows developer, use the strict_gs_check option that has been added in Visual C++ 2005 SP1. This will take care of problem 1, but not problem 2. Other than that, there's not much that can be done other than wait for updates.
This is it for now. If there's interest, I'll go through the rest of the measures from the paper too. Next stop: SafeSEH!