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 [lcamtufat_private] [security] [http://lcamtuf.coredump.cx] <=-=> bash$ :(){ :|:&};: =-=> Did you know that clones never use mirrors? <=-= http://lcamtuf.coredump.cx/photo/
This archive was generated by hypermail 2b30 : Thu Mar 28 2002 - 13:46:29 PST