RE: Behavior analysis vs. Integrity analysis [was: Binary Brutefo rcing]

From: Michael Wojcik (Michael.Wojcikat_private)
Date: Fri Mar 29 2002 - 08:32:44 PST

  • Next message: pr0ix: "Statement on "Re: New Binary Bruteforcing Method Discovered""

    > From: auto12012 auto12012 [mailto:auto12012at_private]
    > Sent: Thursday, March 28, 2002 3:55 PM
    
    > I cannot tell if it will cause proper behavior in all cases, but I can
    > tell if it might not, and under which set of conditions it might not,
    > and if this set of conditions, regardless of possible or not, can be 
    > driven by untrusted interests, without having to follow the path
    > itself. That covers the complete range that forms the notion of
    > 'vulnerability'. (as I, and I believe a majority of people, define it)
    
    Well I, for one, think you have a rather impoverished conception of
    "vulnerability".  And I'd like to see some evidence that that's how "a
    majority of people" (or "most people", as you claim later) define it.  I see
    plenty of security experts using some variation on "a secure program does
    what it is supposed to do, and nothing else"; the corresponding definition
    of "vulnerability" would be any mechanism by which a program could be made
    to exhibit insecure behavior.
    
    Note that under such a definition what constitutes a secure program, or a
    vulnerable one, cannot be determined by program logic alone, because the
    metric is extra-computational: "supposed to do" requires supposition, which
    is not a feature of logic.  A program that is logically correct in its trust
    partitioning of data flows can still present a vulnerability to the security
    of the system as a whole.  Accident is the obvious example: if a trusted
    user can accidentally remove important data, for example, then the system
    has a vulnerability in the form of insufficient protection against mistakes.
    (Note further that it's easy to extend this kind of vulnerability into one
    where active malice leads to a breach, for example through social
    engineering.  The malicious data flow can be decoupled from the vulnerable
    program.  It would be quite a stretch to call that "driven by untrusted
    interests" - and if you're willing to do so, then no data flow can be
    guaranteed untainted.)
    
    In practice, of course, it's infeasible to vet most software against every
    possible threat, to test every possible state.  But good professionals
    recognize the limitations of various analysis techniques and do what they
    can; they don't declare that one magic bullet reveals all possible
    weaknesses.  Particularly not by narrowing definitions to suit the
    capabilities of the tools they promote.
    
    Michael Wojcik
    Principal Software Systems Developer, Micro Focus
    Department of English, Miami University
    



    This archive was generated by hypermail 2b30 : Fri Mar 29 2002 - 12:04:28 PST