> > > > Most likely been done already. In the 70's. At the time when information > > security was a science. > >No. That is not what I meant. To tell whether ftp daemon is working well >or not, you have to know what behavior is appropriate for ftp daemon, and >what is not. If FTP daemon can be fooled, without actually inserting >malicious code, to, say, change root's password, this is a vulnerability, >but it does not mean it exhibits some universal "vulnerability pattern" - >it just went off the track and jumped into another, perfectly valid for, >say, passwd utility. So what I am referring to are functional >specifications for this particular application, so all possible behavioral >tracks of the actual code can be compared to what we expect it to do. This >is expensive, lengthy and prone to design errors. > >And again, I do not buy the argument that there's one fixed, static point >that does not depend on the execution path that can be considered a point >of vulnerability. No. 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), with the lower integrity of the subject (non-root user), then I am disapointed. 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. > >-- >_____________________________________________________ >Michal Zalewski [lcamtufat_private] [security] >[http://lcamtuf.coredump.cx] <=-=> bash$ :(){ :|:&};: >=-=> Did you know that clones never use mirrors? <=-= > http://lcamtuf.coredump.cx/photo/ > > _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com
This archive was generated by hypermail 2b30 : Thu Mar 28 2002 - 13:39:36 PST