Re: Behavior analysis vs. Integrity analysis [was: Binary Bruteforcing]

From: Michal Zalewski (lcamtuf@coredump.cx)
Date: 03/28/02 

Date: Thu, 28 Mar 2002 15:22:34 -0500 (EST)
From: Michal Zalewski <lcamtuf@coredump.cx>
To: auto12012 auto12012 <auto12012@hotmail.com>

On Thu, 28 Mar 2002, auto12012 auto12012 wrote:

> Given this is your reply to my previous statement, you obviously mistake
> 'understanding logic' (or 'understanding on what basis the process is to
> behave') for 'understanding behavior in certain conditions'. The
> difference is as much important as the difference between a compiler and
> a machine. Saying that the behavior of a process cannot be predicted
> under all circumstances is true, but saying that the logic of a process
> cannot be deduced is wrong.

The logic is the program. Program is completely self-explanatory when it
comes to documenting the logic of the process. We can talk about specific
representation of the logic behind the code, basically converting one form
of code into another, perhaps higher level description of the same
algorithm. But now, we want to know whether following one particular
algorithm will IN ALL CASES cause proper behavior. We're not interested in
"most of the cases" - this stage is debugging/QA, not security testing.
We want our code to do what it is supposed to do and nothing else, no
matter what.

To make general assumptions about how the program will work, we will be
fine with one or another model of the mechanism. But to check that a
complex algorithm will in all cases result in a proper output, we have to
evaluate the algorithm going thru every single case, or find a way to tell
how will it behave without it - which can't be really done for every
single code. Again, the whole point of this discussion was to challenge
the claim of "finding all vulnerabilities", not finding some
vulnerabilities.

> What you track is integrity, not data itself. The concept is much more
> abstract. If you fail to see it, check out
> http://pag.lcs.mit.edu/6.893/readings/denning-cacm76.pdf, section (3)
> Enforcement of Security.

We certainly don't understand each other. Secure information flow !=
security. A vulnerability can be everything, from unexpected halt to
almost any other difference between various expectations and actual
behavior. Not always information flow is compromised. And models that
guarantee secure information flow do not automatically have any
application to existing real-world code that might not conform to any
formal flow model and yet be secure.

You didn't show me there's a way to tell whether any potential security
problem (which pretty much can be defined as "any undesirable state of the
machine") will be present or not by just looking at any code, without
tracing every possible execution path. You fail to address issues I raised
in my previous post.

> Read the information I forwarded you to first, then I hope you will make
> the respective distinctions between 'vulnerability regardless of data
> being delivered' [...]

I see the distinctions clearly. I have no idea what makes you think I do
not. "Vulnerability dependent on data being delivered" is a different
concept that "vulnerability dependent on the integrity of data being
delivered". The vulnerability can be triggered by a presence of certain
input (such as certain option -c that accidentally calls wrong code and
does reboot() when certain date and time is set), but without compromising
data [flow] integrity. The only way to tell the vulnerability occours is
to trace the execution path and see if it reachs the critical point in a
specific state. 

-- 
_____________________________________________________
Michal Zalewski [lcamtuf@bos.bindview.com] [security]
[http://lcamtuf.coredump.cx] <=-=> bash$ :(){ :|:&};:
=-=> Did you know that clones never use mirrors? <=-=
          http://lcamtuf.coredump.cx/photo/

Relevant Pages

  • Re: Newby simple question...
    ... Usually the algorithm itself (if ... like AES) is the least vulnerable part of the system. ... In other words, if you use something like AES, the security of the ... The vulnerability will be in the method you use to share ...
    (sci.crypt)
  • SecurityFocus Microsoft Newsletter #165
    ... Tenable Security ... distribute, manage, and communicate vulnerability and intrusion detection ... Microsoft Internet Explorer MHTML Forced File Execution Vuln... ...
    (Focus-Microsoft)
  • SecurityFocus Microsoft Newsletter #174
    ... This issue sponsored by: Tenable Network Security ... the worlds only 100% passive vulnerability ... MICROSOFT VULNERABILITY SUMMARY ... Novell Netware Enterprise Web Server Multiple Vulnerabilitie... ...
    (Focus-Microsoft)
  • [NT] Cumulative Security Update for Internet Explorer (MS04-038)
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... Get your security news from a reliable source. ... CSS Heap Memory Corruption Vulnerability, ... Microsoft Windows NT Server 4.0 Terminal Server Edition Service Pack 6 ...
    (Securiteam)
  • SecurityFocus Microsoft Newsletter #171
    ... Better Management for Network Security ... GoodTech Telnet Server Remote Denial Of Service Vulnerabilit... ... ASPApp PortalAPP Remote User Database Access Vulnerability ...
    (Focus-Microsoft)