full-disclosure - Vulnerability Disclosure Technics

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks@...edu)
Subject: Vulnerability Disclosure Technics 

On Sat, 19 Jun 2004 21:41:35 PDT, "Mr. John" <johnspood@...oo.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...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20040621/8e7d4237/attachment.bin