Vulnerability Development mailing list archives
Re: Behavior analysis vs. Integrity analysis [was: Binary Bruteforcing]
From: Michal Zalewski <lcamtuf () coredump cx>
Date: Thu, 28 Mar 2002 15:22:34 -0500 (EST)
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/
Current thread:
- Re: Behavior analysis vs. Integrity analysis [was: Binary Bruteforcing] auto12012 auto12012 (Mar 28)
- Re: Behavior analysis vs. Integrity analysis [was: Binary Bruteforcing] Michal Zalewski (Mar 28)
- Re: Behavior analysis vs. Integrity analysis [was: Binary Bruteforcing] Michal Zalewski (Mar 28)
- Re: Behavior analysis vs. Integrity analysis [was: Binary Bruteforcing] Syzop (Mar 28)
- Message not available
- Re: Behavior analysis vs. Integrity analysis [was: Binary Bruteforcing] Lincoln Yeoh (Mar 28)
- <Possible follow-ups>
- Re: Behavior analysis vs. Integrity analysis [was: Binary Bruteforcing] auto12012 auto12012 (Mar 28)
- Re: Behavior analysis vs. Integrity analysis [was: Binary Bruteforcing] Michal Zalewski (Mar 28)
- Re: Behavior analysis vs. Integrity analysis [was: Binary Bruteforcing] auto12012 auto12012 (Mar 28)
- Re: Behavior analysis vs. Integrity analysis [was: Binary Bruteforcing] Michal Zalewski (Mar 28)
- Re: Behavior analysis vs. Integrity analysis [was: Binary Bruteforcing] auto12012 auto12012 (Mar 28)
- Re: Behavior analysis vs. Integrity analysis [was: Binary Bruteforcing] auto12012 auto12012 (Mar 29)