> > 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. 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) > >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. I believe what you try to challenge here is the claim of "finding all bugs", not "finding all vulnerabilities". (as most people and I define it) > > > 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. I admit that I do not believe a vulnerability can be everything. I also do not believe an unexpected halt of service is a vulnerability, unless it has been driven by the untrusted subject, in which case it becomes a compromise of integrity of a process (service provision) by information of lower integrity. I also do not think that everything that does not match the expectation of a behavior (bug?) is a vulnerability, as I stated earlier. > >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. I did not. I only do not classify a vulnerability as any undesirable state of the machine. A machine that fails to comply with its initial requirements is not what I systematically define a vulnerable machine. Of course, you could define a vulnerability as such, but I believe you would probably be the only one around to do so. Otherwise, there would be an affluence of useless bugs on this mailing list. (Oh, wait, there is!) To tell you the truth, I now understand your point of view and the necessity of evaluating every possible execution path, but only in the case where you define a vulnerability as you defined it earlier. Personally, I am more interested in the aspect of 'security compromise' than 'failure to meet functional requirements'. > > > 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. That was your reference to using 'grep' to find vulnerabilities in an execution path independent manner ;) >"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 [lcamtufat_private] [security] >[http://lcamtuf.coredump.cx] <=-=> bash$ :(){ :|:&};: >=-=> Did you know that clones never use mirrors? <=-= > http://lcamtuf.coredump.cx/photo/ > > _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com
This archive was generated by hypermail 2b30 : Thu Mar 28 2002 - 15:21:51 PST