Nicholas Weaver wrote: > There already IS some randomization in Sapphire's host, > and the Sapphire code goes through the routine to disambiguate GetProcAddress and similar APIs were not created with security in mind. They were built for the benefit of programmers, who also were not created with security in mind. It is possible to intercept every call to GetProcAddress and determine whether or not the call should be authorized based on a predetermined list of known valid callers (runtime call stack analysis). This list of authorized callers must be constructed through the use of forensic profiling tools in the case of other people's binaries, but can be constructed with the help of additional API calls in the case of one's own code. Call a profiling/tracing API before calling GetProcAddress. After compilation but before deployment to production boxes you simply execute the code in profile mode to generate a list of authorized callers. This list is then configured as a static security setting adhered to by the security layer that sits between GetProcAddress and the rest of the virtual world. For programmers doing development one simply instructs such security layer to allow all callers from the process that is under development. A properly security-hardened binary DOES NOT require support for arbitrary relocations, arbitrary dynamic library injection, arbitrary code injection resulting in new execute paths defined at run-time, and the type of programmability required by software developers. Once code has been compiled and linked, even when that code makes use of dynamic libraries, there is no longer any unknown. With the exception of those very few situations in which self-modifying code techniques are employed (certain compilers, etc. -- which in general are broken by noexec stack implementations, anyway) all possible execute paths through the binary and its related libraries are known at compile-time. Failing to perform any sort of forensic profiling of these static execute paths, and failing to restrict use of the microprocessor unless the execute path attempting to control it conforms to an authorized forensic profile results in unnecessary run-time programmability that causes the vast majority of infosec vulnerabilities. Execute restrictions based on such forensic profiling can be built for Windows, without access to its source code and without losing binary backwards compatibility. It is far better to build this countermeasure at the source level. This solution brings the essential security benefits of non-programmable firmware-based embedded systems to our programmable computers and it is long overdue. Sincerely, Jason Coombs jasonc@science.org
