Last updated at Wed, 26 Jul 2017 18:35:26 GMT
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.
