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

From: Michal Zalewski (lcamtuf@bos.bindview.com)
Date: 03/28/02 

Date: Thu, 28 Mar 2002 15:30:16 -0500 (EST)
From: Michal Zalewski <lcamtuf@bos.bindview.com>
To: auto12012 auto12012 <auto12012@hotmail.com>

On Thu, 28 Mar 2002, auto12012 auto12012 wrote:

> That is too bad. If you fail to understand that ftp daemon, in your
> example, is not vulnerable because it adopts a behavior that it is not
> excepted to follow, but simply because it compromises the integrity of
> an object (root password)

And how can you tell it does without examining the execution path? It is
not enough to say that there is a situation where the compromise is
possible because of insufficiently strict data flow control and
separation, but you can't tell this is a threat unless you know it
actually can happen.

> If I do not believe vulnerability is related to execution path, it is
> not because I believe it is not dependent of anything, but simply
> because I believe it is dependent of something that is of much higher
> abstraction: logic.

We probably have a different understanding of the same term.
"Vulnerability" as a term describing "broken behavioral logic" versus
"vulnerability" describing actual problem that poses a real threat. The
problem is that, first of all, building high-level abstracts in automated
process does not always deliver complete models, and that with our
existing code we have to deal with, in most cases, we'd be drowned in the
sea of false positives triggered by detecting "approach that does not
conform to established secure data flow models", but does not cause any
actual exposure. 

-- 
_____________________________________________________
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/