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
jasoncscience.org

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]