[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080602141053.GA25437@openwall.com>
Date: Mon, 2 Jun 2008 18:10:53 +0400
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: code reviews (was: ARP handler Inspection tool released)
On Mon, Jun 02, 2008 at 02:40:28PM +0200, Nico Golde wrote:
> Is this really appropriate content for this list? I guess
> all of us read full-disclosure, bugtraq etc. and this is a
> "list for open source software authors and vendors to
> discuss public security issues". I don't think that the nth
> cross-post of software announces belong to this list.
I don't mind seeing announcements of security tools related to Open
Source software in here, as long as this does not dominate the list
traffic (in which case we can always setup another list just for those
announcements). I understand that others may have different opinion
(please speak up).
However, Andrea's message was not a mere tool announcement, it also had
this line:
"I need testing and code revision, thank you."
This looks like a request for community review, maybe a security audit.
To some extent, this is similar to my posting of the OpenSSH key
blacklisting patch, where I also asked for community review (but did not
get much in response...) - although that one was also on-topic because
it was discussion of addressing a public security issue between vendors.
I feel that it'd be nice if a list existed where one could ask for some
source code to be reviewed - and get useful feedback. We had the
security-audit list in late 1990s that kind of worked like that; one of
the most active contributors was Chris Evans, who later wrote vsftpd.
Unfortunately, I'm afraid that people like Chris are way too busy these
days to bother reviewing some code that might never see widespread use;
in fact, they're probably too busy to review code that is in widespread
use unless they choose to for some specific reason (e.g., if it's part
of a project they're interested in or if it's requested and sponsored by
a client or employer). I know that this is usually the case for me. ;-)
To give a specific example, most recently I reviewed the Debian/Ubuntu
OpenSSH key blacklisting patch (including the sshd and ssh-vulnkey bits),
reporting the (relatively minor) vulnerabilities to Colin Watson and
vendor-sec. Since those were non-public vulnerabilities (albeit minor
ones), and Colin did not ask for a public review, I felt it was polite
to handle them in private. Colin has already revised the patch based on
my feedback. Why did I do it? That's for several reasons at once: this
work was closely related to Openwall's own patch for the OpenSSH package
in Owl, it was sponsored by a client of ours (I wish I could get "proper"
credits in the changelog, which would really be of help next time - but
perhaps that'd be a stretch), Colin submitted the patch for review to
vendor-sec (such that I, not being a Debian user, did not have to locate
the patch on my own), and finally I wanted to help the Open Source
community and specific friends of mine who are Debian/Ubuntu users.
When I had all of these reasons at once, I went for the (minor) effort.
But when that is not the case... I usually don't - got way too much on
my plate.
Do we have people like the security-audit activists of late 1990s in
here? (I know that some of the same people are in fact in here, but I'm
sure that they have changed - similarly to the way I have changed. So I
mean people "like" those who were active on security-audit at the time
and who are in this shape now.)
In case we do, I would not mind having such community code reviews occur
on this list. I think they would be on-topic. In fact, Sebastian
Krahmer even created a section on the wiki for the code reviews - but
neither he nor anyone else contributed to it. Sebastian? Anyone else?
Please defend yourselves. ;-)
Oh, and requests for code reviews should probably be more specific than
posting an URL for a tarball. If you can identify specific functions in
your code that are especially security-critical, post just those - in a
form suitable for quoting. I find it highly unlikely that anyone, even
the kind of people I mentioned above, would bother downloading a tarball
of something they had never heard of to do a security audit of it -
unless this is paid work.
And, by the way, at Openwall we did some paid audits of Open Source
software, and this is something we like to do - except that we're
usually limited (even if not always legally) in our ability to make the
audit results public. Luckily, our findings were not being ignored so
far, and the software in question did improve as a result - which is
understandable, given that there was a cost involved. I know that we're
indeed not unique in this fairly new "market", although the demand
appears to be mostly for auditing PHP applications, whereas our
(preferred) focus is different.
Now, do any/all of you find my posting appropriate? ;-)
Alexander
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
