Wednesday, August 16, 2006

Putting the fun in browser fun

During the month of July, H D posted one browser bug each day on the browser fun blog. The majority of these bugs centered around issues that are typically regarded as non-exploitable, such as NULL pointer dereferences and stack overflows (not to be confused with stack-based buffer overflows). Though this may be the case, there is an interesting exploitation vector that can be applied to browsers that run on Windows, such as Internet Explorer, that can potentially leverage code execution from otherwise non-exploitable issues. The details about how this can be accomplished are described in a paper that Skywing and I have published entitled Exploiting the Otherwise Non-Exploitable on Windows.

The basic idea behind this technique involves abusing a design flaw in the way the SetUnhandledExceptionFilter routine operates which results in an attacker being able to point the top-level unhandled exception filter to an invalid address. Once this occurs, all that's necessary is to use a heap spraying technique to place code at the location that the top-level unhandled exception filter points to. The final step is to trigger an unhandled exception, such as a NULL pointer dereference, that will result in the execution of arbitrary code. Abusing the top-level unhandled exception filter has been done in the past, but this technique illustrates an indirect way to gain control that does not rely on the ability to perform a 4x4 overwrite. Furthermore, it is not limited by improvements that have been made to protect the top-level unhandled exception filter, such as through the use of function pointer encoding.

The important take away is that the use of this technique means that all of the otherwise non-exploitable issues reported in H D's postings can potentially be exploited in a reliable fashion through the use of this technique. However, it will only work on machines that are not patched with the latest critical updates since this issue has now been addressed by the patch that was created for MS06-051. At any rate, it would be interesting to know what other applications might be vulnerable to this type of attack as well as other interesting ways to achieve it in Internet Explorer.

4 comments:

Anonymous said...

>> stack overflows (not to be confused with stack-based buffer overflows)

Unfortunately, i AM confused about the difference between stack overflows and stack-based buffer overflows.... and are stack-based buffer overflows just long for buffer overflows?

If someone could explain this im sure other people are probably confused as well... thanks!

hdm said...

A "stack overflow" is a condition caused by the process running out of stack space (allocated memory pointed at by the ESP register). It is not a buffer overflow in any sense of the term.

_theXman_ said...

One little "handy" tool:

https://www.securinfos.info/outils-securite-hacking/uSEH.rar

E:\0HACK>uSEH.exe
SetUnhandledExceptionFilter 0x021CEC81

Cheers

Anonymous said...

Hi,

Does the OS have separate stack area for itself(operating system) and separate stack area for the application ?
Or
Does the stack area of the application will be part of the stack(bigger stack) of the Operating System ?

I do not find Clear information w.r.t this on the internet. Any ideas ?

Thx in advans,
Karthik Balaguru