Script Kiddies and Open Source or Vanity Fair Rulez

The results of the discussion of the previous question can be logically extended to the security area. That lead us to the logical conclusion that OSS products cannot claim superiors security. Generally speaking among three free UNIXes (OpenBSD, FreeBSD, and Linux), it's Linux that is the most insecure flavor and it will probably stay this way. And any organization that is using or plan using Linux should be aware about the risks and consider OpenBSD among other alternatives, especially for critical infrastructure machines like firewalls, mail servers, dns servers, etc.  

But that's not what we want to discuss. We will discuss here the dangerous trend to extend open source concepts to the publishing of exploits. Here we can see that there are some really interesting side effects of opening code. As one Slashdot reader put it:

Although I would not go that far as to claim that  security tools produces are a special kind of weapon dealers, I would agree with Marcus Ranum (see also discussion on slashdot) that script kiddies are dangerous, not merely annoying, and that "vanity fair rulez" -- many vulnerabilities that are being disclosed are researched for the sole purpose of disclosing them:

"We are creating hordes and hordes of script kiddies," Ranum said. "They are like cockroaches. There are so many script kiddies attacking our networks that it's hard to find the real serious attackers" because of all the chaotic noise.

"A lot of the " he said. "Someone who releases a harmful program through a press release has a different agenda than to help you."

Over the next few years, society's tolerance of hackers will lessen once hacking is regarded as "non-ideological terrorism," he said. As home users increasingly find themselves the target of hackers, there will be less and less patience with break-ins.

"In the next five years, we are going to move to a counterterrorism model," he said. "It will turn into a witch hunt, unless we stop the script kiddies today."

Ranum's message to the creators of tools: "Why don't you do something useful."

As Elias Levy noted in his paper "Is Open Source really more secure than closed?" :

If Open Source were the panacea some think it is, then every security hole described, fixed and announced to the public would come from people analyzing the source code for security vulnerabilities, such as the folks at OpenBSD,  the Linux Auditing Project, or the developers or users of the application.

But there have been plenty of security vulnerabilities in Open Source Software that were discovered, not by peer review, but by black hats. Some security holes aren't discovered by the good guys until an attacker's tools are found on a compromised site, network traffic captured during an intrusion turns up signs of the exploit, or knowledge of the bug finally bubbles up from the underground.

Why is this? When the security company Trusted Information Systems (TIS) began making the source code of their Gauntlet firewall available to their customers many years ago, they believed that their clients would check for themselves how secure the product was. What they found instead was that very few people outside of TIS ever sent in feedback, bug reports or vulnerabilities. Nobody, it seems, is reading the source.

The fact is, most open source users run the software, but don't personally read the code. They just assume that someone else will do the auditing for them, and too often, it's the bad guys.

Old versions of the Sendmail mail transport agent implemented a DEBUG SMTP command that allowed the connecting user to specify a set of commands instead of an email address to receive the message. This was one of the vulnerabilities exploited by the notorious Morris Internet worm.

Sendmail is one of the oldest examples of open source software, yet this vulnerability, and many others, lay unfixed a long time. For years Sendmail was plagued by security problems, because this monolithic programs was very large, complicated, and little understood but for a few.

Vulnerabilities can be a lot more subtle than the Sendmail DEBUG command. How many people really understand the ins and outs of a kernel based NFS server? Are we sure its not leaking file handles in some instances? Ssh 1.2.27 is over seventy-one thousand lines of code (client and server). Are we sure a subtle flaw does not weakening its key strength to only 40-bits?

...While some of the binaries are cryptographically signed to verify the identity of the packager, they make no other guarantees. Until the day comes when a trusted distributor of binary open source software can issue a strong cryptographic guarantee that a particular binary is the result of a given source, any security expectations one may have about the source can't be transferred to the binary.

But things are not that bad :-). I would like to stress again that the quality of open source products varies greatly, much like the quality of closed source products: