Felix von Leitner wrote:

>The problem about auditing is that there really is no reason for people
>to audit code. There is no reward. On the contrary, sometimes you are
>even threatened by some lawyer running wild.
>
Yet there seem to be lots of people doing it anyway (Zalewski, Guninski,
w00w00, etc.). People do this work. We're trying to preserve the value
of the work being done.

> And you can't even make
>yourself a name by auditing code and finding bugs! There are so many
>advisories out there that it's nothing special to write an advisory any
>more. With a hundred more or less unprofessional bulk advisories every
>week, nobody remembers the names of the auditors.
>
Yes, that's a problem. The Sardonix scoring system is designed to
address this problem. Yes, its a question whether this will work. That's
part of why this is research.

>Auditing code is a not a job to be proud of.
>
Excuse me? It most certainly is.

> It is infrastructure work.
>
And infrastructure work, especially that requires technical proficiency,
and is un-paid, is certainly something to be proud of.

>And contary to other infrastructure work (like writing new code, for
>example!), it is not even creative or intellectually challenging.
>
It is not creative, but it is intellectually challenging. This it is
highly apropriate for people who want to contribute to the community,
but don't have a great new idea for a program to write. With appropriate
guidance, auditing is also appropriate for the novice developer: the
auditor learns through exposure what to do, and what not to do.

>Isn't it a better use of our time to start writing software from a
>security point of view?
>
There are lots of things people can do to address the security problem.
Auditing code is one of them. As Felix observed in his swipe at Kurt,
telling other people what to do is not one of them :-)

>Also, it helps us focus our resources. If we proceed with the auditing,
>we should first find a small basis that can sustain other software.
>I'm talking about postponing an audit of sendmail if we already audited
>qmail or postfix.
>
Auditors are donating free labor, so they get "cook's privilege": sie
who cooks gets the privilege of choosing the dish. Auditors can and will
audit whatever they want. We can (and did) suggest packages that need
auditing, but they will do what they want. IMHO, audit "priority ~=
apparent vulnerability * popularity", making an audit of sendmail a much
higher priority than an audit of qmail or postfix.

>Like in other parts of the IT industry, pressure can be put on software
>authors and vendors by producing a standard paper that states the
>minimum requirements for secure software. It could just start with the
>simple stuff, like "don't use tmpnam", or "for each use of a static
>buffer in your code, provide a separate test case that demonstrates
>there overflow handling is done properly". Once this kind of paper
>exists, there will be a reason to write better code. Currently, there
>isn't.
>
But this paper does exist, from multiple sources (look at the bottom of
this list, http://sardonix.org/Auditing_Resources.html and also see Matt
Bishop's landmark paper http://nob.cs.ucdavis.edu/~bishop/secprog/
<http://nob.cs.ucdavis.edu/%7Ebishop/secprog/> )

Clearly these papers have helped, but equally clearly, they have not
solved the problems. Auditing is needed not just because some developers
refuse to read or follow such standards, but also because humans make
mistakes, and may fail to completely or correctly follow all rules
perfectly.

Auditing and coding standards are complementary approaches to the same
problem.

Crispin

-- 
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc. http://wirex.com
Security Hardened Linux Distribution:       http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html
        The Olympic Games: A Century of Corruption and Graft
	     The FIS: Crushing the soul of snowboarding

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