The myth of open source security
"Everyone using Mailman, apparently, assumed that someone else had done the proper security auditing, when, in fact, no one had. " |
The core open source phenomenon responsible for making code secure is the "many eyeballs" effect. With lots of people scrutinizing a program's source code, bugs--and security problems--are more likely to be found. Why do programmers look at source code? Mostly for their own benefit: They've found a piece of open source software useful, and they want to improve or change it for their own specific needs. Sometimes, too, source code attracts scrutiny just to make sure it meets certain needs, even when there's no intention of modifying it. Companies that require a high level of security, for example, might do a code review as part of a security audit. This could be done for any software product where the source is available, of course, regardless of whether it's open source or produced commercially.
"If you're running a Mailman version earlier than 2.0 beta, you're advised to ugrade immediately. The latest version can be found on the Mailman Web site at http://www.list.org. " |
Software developers have a tendency to ignore security up front and try to bolt it on afterwards. Even worse, most developers don't necessarily know much about security. Many programmers know a bit about buffer overflows and are probably aware of a handful of functions that should be avoided. But many of them don't understand buffer overflows enough to avoid problems beyond the handful of dangerous calls they know. And when it comes to flaws other than buffer overflows, the problem gets worse. For example, it is common for developers to use cryptography but misapply it in ways that destroy the security of a system. It is also common for developers to add subtle information leaks to their programs accidently. It's really common to use encryption that is too weak and can easily be broken. It's also common for people to exchange cryptography keys in a way that's actually insecure. People often try to hand roll their own protocols using common cryptographic primitives. But cryptographic protocols are generally more complex than one would expect, and are easy to get wrong. Far too trusting So despite conventional wisdom, the fact that many eyeballs are looking at a piece of software is not likely to make it more secure. It is likely, however, to make people believe that it is secure. The result is an open source community that is probably far too trusting when it comes to security. Again, take the case of the open source mailing list manager Mailman, which I helped write. For three years, until March 2000, Mailman had a handful of glaring security problems in code that I wrote before I knew much about security. An attacker could use these security holes to gain access to the operating system on Linux computers running the program.
These were not obscure bugs: anyone armed with the UNIX command grep and an iota of security knowledge could have found them in seconds. Even though Mailman was downloaded and installed thousands of times during that time period, no one reported a thing. I finally realized there were problems as I started to learn more about security. Everyone using Mailman, apparently, assumed that someone else had done the proper security auditing, when, in fact, no one had.
And if three years seems like a long time for security holes to go undetected, consider the case of Kerberos, an open source security protocol used for authentication. According to Ken Raeburn, one of the developers of the MIT Kerberos implementation, some of the buffer overflows recently found in that package have been there for over ten years. The many-eyeballs approach clearly failed for Mailman. And as open source programs are increasingly packaged and sold as products, users--particularly those who are not familiar with the open source work--may well assume that the vendor they are buying the product from has done some sort of security check on it. Until this week, for example, version 1.0 of Mailman, which contains these security holes, was included in Red Hat Professional Linux version 6.2. (If you're running a Mailman version earlier than 2.0 beta, allow me to suggest that you upgrade immediately. The latest version can be found on the Mailman Web site at http://www.list.org).Page 1 of 2
This article was originally published on June 1, 2000