Uninformed: Informative Information for the Uninformed

Vol 9» 2008.Jan


No Support for SafeSEH

With Visual Studio 2003, Microsoft introduced a compile-time change known as SafeSEH which attempts to act as a mitigation for the SEH overwrite attack vector[5,9]. SafeSEH works by adding a static list of known good exception handlers that are considered valid as metadata within a given binary. Binaries that support SafeSEH allow the exception dispatcher to perform additional checks when dispatching exceptions. The most important check involves determining if an exception handler that is found to exist within the mapped region of a given binary is actually considered to be one of the safe exception handlers. If the exception handler is not a safe exception handler, the exception dispatcher can take steps to prevent it from being called. This behavior works to mitigate the potential exploitation vector.

In order to communicate this information to the exception dispatcher, modern PE files include fields in the load config data directory which hold the offset of the safe exception handler table and the number of elements found within the table. The load config data directory contains meta data that is useful to the dynamic loader such as information about safe exception handlers, the module's global security cookie address, and so on[13]. The following output from dumpbin.exe illustrates what this might look like:

  310751E0 Safe Exception Handler Table
         1 Safe Exception Handler Count

Safe Exception Handler Table

  Address
  --------
  310357D1  __except_handler4

Unfortunately, as with ASLR, the benefits offered by SafeSEH are not complete unless every binary that is loaded into an address space has been compiled to make use of SafeSEH. If a binary has not been compiled to make use of SafeSEH, an attacker may be able to use any address found within the binary's memory mapping as an exception handler in conjunction with an SEH overwrite.