Conclusion

The title of this paper implies that an attacker has the ability to leverage code execution of bugs that would otherwise not be useful, such as NULL pointer dereferences. To that point, this paper has illustrated a technique that can be used to gain control of the top-level unhandled exception filter for an application by making the registration and deregistration process asymmetrical. Once the top-level UEF has been made to point to invalid memory, an attacker can use techniques like heap-spraying to attempt to place attacker controlled code at the location that the now-defunct top-level UEF resided at. Assuming this can be accomplished, an attacker simply needs to be able to trigger an unhandled exception to cause the execution of arbitrary code.

The crux of this attack vector is in leveraging a design flaw in the assumptions made by the way the unhandled exception filter ``chain'' is maintained. In particular, the design assumes that calls made to register, and subsequently deregister, an unhandled exception filter through kernel32!SetUnhandledExceptionFilter will be done symmetrically. However, this cannot always be controlled, as DLLs that register unhandled exception filters are not always guaranteed to be loaded and unloaded in a symmetric fashion. If an attacker is capable of controlling the order in which DLLs are loaded and unloaded, then they may be capable of gaining arbitrary code execution through this technique, such as was illustrated in the Internet Explorer case study in chapter .

While not feasible in most cases, this technique has been proven to work in at least one critical application: Internet Explorer. Going forward, other applications, such as IIS, may also be found to be susceptible to this attack vector. All it will take is a little creativity and the right set of conditions.