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 [lcamtufbos.bindview.com] [security]
[http://lcamtuf.coredump.cx] <=-=> bash$ :(){ :|:&};:
=-=> Did you know that clones never use mirrors? <=-=
          http://lcamtuf.coredump.cx/photo/

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]