Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Aleph1's recent article on securityfocus.com http://www.securityfocus.co m/templates/article.html?id=19 [securityfocus.com] makes many of the same points as you do. As well, he makes the point that the people reading the source may not be knowledgable enough about security issues to properly audit the code. Why else would we keep seeing the same type of exploits being used over and over again (buffer overflows, symlinks, failure to drop privs, bad crypto)? The Dansie Shopping cart problem that recently came through BUGTRAQ is a prime example of this; the source was available, but until something went wrong, nobody thought to check it for security problems. In this case, there was a blatant back door in the code that had been there for some time. This was code written in perl, so there was no excuse not look it over. Come to think of it, what opensource project other than OpenBSD has actually undergone a code audit for security? I don't think there's much of a solution to the problem other than making people aware of the problem, and publicly embarrasing them on mailing lists if they code something insecurely (especially if they put a back door in).