Re: Vulnerability Disclosure Technics

[Valdis.Kletnieks () vt edu]

On Sat, 19 Jun 2004 21:41:35 PDT, "Mr. John" <johnspood () yahoo com>  said:

> Suppose that I am technical chair of a software group
> and   we have a software that security consideration
> is important for us. How can I test our software to
> ensure that no security vulnerabilities (like buffer
> overflow vuln) exists in our software product. Or it
> is question for me how for example eEye find many
> vulnerabilities in software products. Is there a
> regular and formal way? Is there some tools, technics,
> method, ... for this purpose, for finding a
> vulnerability in a software?

Note that the techniques for *finding* holes are totally different from
the techniques for writing software correctly in the first place.

Your best bet for actually doing it right in the first place:

0) Understand that proper design is a better idea than being able to test a
broken design...

1) get copies of Howard's "Writing Secure Code (2nd ed)":
http://www.amazon.com/exec/obidos/tg/detail/-/0735617228/qid=1087847205/sr=1-1/ref=sr_1_1/104-5132183-7002350?v=glance&s=books
or other good book on the subject (I happen to like Howard's book, but others
on the list will certainly have other suggestions), and make sure *all* your
code people read it *and Get It*.  If your programmers Just Don't Get It,
you're screwed no matter how much testing you do.

2) Make sure security is considered in all your design reviews.. Screw-ups like
failing to "canonify a string exactly once and then verify what the string
means" are at the root of essentially all the myriad different unicode/
directory traversal bugs. And usually, getting this sort of thing right during
the design is a lot easier than trying to fix it once you have several hundred
thousand lines of code doing it The Wrong Way.

3) Do proper testing, verification, and source code management (which
you probably should be doing already, anyhow, right? ;)

Hope that helps...

Attachment: _bin
Description: