Bugtraq mailing list archives
RE: Observation on randomization/rebiasing...
From: "Jason Coombs" <jasonc () science org>
Date: Wed, 5 Feb 2003 12:07:58 -1000
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
Current thread:
- Re[2]: Preventing exploitation with rebasing, (continued)
- Re[2]: Preventing exploitation with rebasing dullien (Feb 04)
- RE: Preventing exploitation with rebasing Jason Coombs (Feb 04)
- Re: Preventing exploitation with rebasing Charlie Root (Feb 05)
- Re: Preventing exploitation with rebasing David Litchfield (Feb 05)
- Re: [VulnDiscuss] Re: Preventing exploitation with rebasing Halvar Flake (Feb 05)
- Re: Preventing exploitation with rebasing Brian Hatch (Feb 05)
- Re: Preventing exploitation with rebasing Alan DeKok (Feb 05)
- Re: Can't Preventing exploitation with rebasing bugtraq (Feb 05)
- Re[2]: Can't Preventing exploitation with rebasing dullien (Feb 05)
- Observation on randomization/rebiasing... Nicholas Weaver (Feb 05)
- RE: Observation on randomization/rebiasing... Jason Coombs (Feb 05)
- Re: Preventing exploitation with rebasing Crispin Cowan (Feb 05)
- Re: Preventing exploitation with rebasing David S Goldberg (Feb 05)
- Re: Preventing exploitation with rebasing Alun Jones (Feb 05)
- Re: Preventing exploitation with rebasing Deus, Attonbitus (Feb 06)
- Re: Preventing exploitation with rebasing Bugtraq User (Feb 05)
- Re: Preventing exploitation with rebasing D.C. van Moolenbroek (Feb 05)
- Re: Preventing exploitation with rebasing Michal Zalewski (Feb 05)