> >
> > 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 [lcamtufbos.bindview.com] [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

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