RE: Observation on randomization/rebiasing...

["Jason Coombs" <jasonc () science org>]

There are good reasons for extensible architectures. No changes are needed
in this respect, we simply must restrict the scope of that extensibility at
run-time to authorized add-on modules. Other programmers can make it easier
for us to do so by adding some forensic profiling code to their programs,
but this is not necessary to achieve substantially-improved practical
control over the extensible code modules we allow to execute, including the
ability to detect when arbitrary malicious code succeeds in overflowing a
buffer and smashing the stack. Every path through third-party code that we
have not profiled and explicitly authorized is simply denied by default,
including portions of third-party code that are not harmful or of malicious
foreign origin, so that in essence the defense says:

"We will only allow code to execute that we have previously executed during
forensic testing. Everything else is denied by default until we analyze its
origin and intended function."

Jason Coombs
jasonc () science org

-----Original Message-----
From: Michael Wojcik [mailto:Michael.Wojcik () MicroFocus com]
Sent: Wednesday, February 05, 2003 10:43 PM
To: BugTraq
Cc: jasonc () science org; Nicholas Weaver
Subject: RE: Observation on randomization/rebiasing...


> From: Jason Coombs [mailto:jasonc () science org]
> Sent: Wednesday, February 05, 2003 5:08 PM

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

There are plenty of examples of programs and libraries that by design load
and execute independently-developed code: browser plugins, ISAPI, and so
forth.  Leaving aside for the moment the question of whether this is a Good
Thing, or whether it fits someone's definition of "a properly
security-hardened binary", it's certainly a popular approach.  The security
community has not to date had much luck convincing users and programmers to
adopt even its uncontroversial recommendations; I doubt you'll get any
traction with this one.

Michael Wojcik
Principal Software Systems Developer, Micro Focus