RE: Observation on randomization/rebiasing...

From: Jason Coombs (jasoncat_private)
Date: Thu Feb 06 2003 - 09:21:19 PST

  • Next message: Seth Breidbart: "Re: Preventing exploitation with rebasing"

    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
    jasoncat_private
    
    -----Original Message-----
    From: Michael Wojcik [mailto:Michael.Wojcikat_private]
    Sent: Wednesday, February 05, 2003 10:43 PM
    To: BugTraq
    Cc: jasoncat_private; Nicholas Weaver
    Subject: RE: Observation on randomization/rebiasing...
    
    
    > From: Jason Coombs [mailto:jasoncat_private]
    > 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
    



    This archive was generated by hypermail 2b30 : Thu Feb 06 2003 - 10:49:24 PST