On Thu, 28 Mar 2002, auto12012 auto12012 wrote: > >And that's not all - our "endless loop" condition is pretty clear in this > >particular case, but sometimes it is not that trivial. Think about > >authentication bypassing, etc. There needs to be a model of an erratic > >behavior for this particular program, and the model itself must be > >designed without flaws, which is not trivial. But I am not gonna argue > >here - it is certainly doable and being done - it is just expensive, time > >consuming and prone to problems. > > 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. It can be simply a design flaw in a perfectly implemented project that opens some back doors (for example, internal state machine is not properly maintained in certain conditions and some sequence of commands can bypass authentication). There does not have to be a buffer overwrite or such. -- _____________________________________________________ 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 - 09:16:05 PST