The thing about open source software projects is that they can be a lot more secure than close source projects.
In saying this, though, the things that make open source programs safe, like being able to access the source code, and the reality that there are a huge number of people that can fix holes in the security system, can also be cause for a false sense of security.
The idea of open source being protected and safe comes from the idea that there are many people looking at it.
With many people looking at a program’s source code, then surely security issues are a lot more likely to be located and eradicated, right?
Why do programmers choose to look at source code? For the most part, it’s for selfish reasons – they have found open source software that they find helpful, and they want to adjust it to suit their personal needs.
Sometimes, the source code attract scepticism to make sure that it meets certain requirements, even when the person has no intention of doing anything to it.
Brands that need a high level of online security, for example, might review the code as part of their general security audit. Of course, this could be done for any software product where the source is open to the public.
The thing about source code is that it can also attract the attention of the programmer, for reasons of personal gain.
There are some people that might hope to find security issues within code, so that they can create a name for themselves in the security network.
Perhaps they have an altruistic side, and they want other people to know about any security issues.
There are many programmers out there that are willing to share information about security breaches and sources of vulnerability, including posting this information to a mailing list so that it’s not so out in the open.
The reality is, there is always going to be someone feeling sceptical about source code, because they want to locate something that nobody else has.
You Might Not Always See it
When people are motivated to scrutinize a source code for whatever reason, it is easy to make the assumption that the open source software has been carefully looked over, and as a result it is safe. However, this isn’t necessarily true.
There are actually a lot of things that can discourage people from looking at a source code. Of course, one reason for this could be that it looks like a huge mess, and you can’t be bothered unravelling it.
When source code is hard to understand and decipher, then naturally there are going to be fewer people looking at it.
People that use source code programs are likely to look at the source code when they think they see something that they would like to be different.
Sadly, this doesn’t necessarily mean that the program gets a free security audit, it just has people looking at certain parts of it that they want to change.
A lot of the time, this is just a tiny part of the entire source code. The other thing is that if someone is distracted with the idea of adding something to the source code they aren’t necessarily on the lookout for security breaches.
A lot of the time, software developers have a habit of ignoring security completely, and then trying to attach it at a later date.
Or, even worse, there are some programmers out there that don’t actually know all that much about security. There are a lot of programmers out there that know a little bit, but many of them don’t understand as much as you might think, certainly not enough to keep the source code secure.
An example of this is that it’s common for developers to use cryptography, but it’s also common for them to misapply it, which could end up destroying the security of a system completely.
It’s also common for programmers to accidentally add information leaks to the program. This way, the encryption weakens, and it can easily be infiltrated and broken.
In general, cryptographic protocols are a lot more complicated than you might think, and can easily be gotten wrong.
Way Too Trusting
So, despite what is conventional in terms of programming wisdom, the reality of lots of eyes on a source code doesn’t necessarily make it more secure. This is likely to make people at least feel like it is secure.
As a result, the open source community in general becomes way too trusting.
When you’ve got source code that is trusted by the community as a whole, the risk of it being hacked or phished by someone who knows what they’re doing becomes greater, and then the entire system can be taken down easily, without too much trouble.
This is why it’s important that a company is able to school its programmers on what good security looks like when it comes to source code, and how to implement good security measures, so that when they go in to change something about the source code, these security measures aren’t weakened in any way.
Having a secure source code is numero uno when thinking about maintaining a good level of security around all of your company’s data online.
Security: Tougher Than It Looks
Even if you get the right kind of people doing the right kinds of things, you may have problems that you never hear about.
Security problems are often incredibly subtle, and may span large parts of a source tree.
It is not uncommon to have two or three features spread throughout a program, none of which constitutes a security problem alone, but which can be used together to perform a security breach.
For example, two buffer overflows recently found in Kerberos version 5 could only be exploited when used in conjunction with each other.
As a result, doing security reviews of source code tends to be complex and boring, since you generally have to look at a lot of code, and understand it pretty well. Even many experts don’t like to do these kinds of reviews.
And even the experts can miss things. Consider the case of the popular open source FTP server wu-ftpd. In the past two years, several very subtle buffer overflow problems have been found in the code.
Almost all of these problems had been in the code for years, despite the fact that the program had been examined many times by both hackers and security auditors.
If any of them had discovered the problems, they didn’t announce it publicly. In fact, the wu-ftpd has been used as a case study for vulnerability detection techniques that never identified these problems as definite flaws.
One tool was able to identify one of the problems as potentially exploitable, but researchers examined the code thoroughly for a couple of days, and came to the conclusion that there was no way that the problem identified by their tool could actually be exploited.
Over a year later, they learned that they were wrong, when an expert audit finally did turn up the problem.
In code with any reasonable complexity, it can be very difficult to find bugs. The wu-ftpd is less than 8000 lines of code long, but it was easy for several bugs to remain hidden in that small space over long periods of time.
To compound the problem, even when people know about security holes, they may not get fixed, at least not right away.
Even when identified, the security problems in Mailman took many months to fix, because security was not the the core development team’s most immediate concern.
In fact, the team believes one problem still persists in the code, but only in a configuration that we suspect doesn’t get used.
An Army In My Belly
The single most pernicious problem in computer security today is the buffer overflow. While the availability of source code has clearly reduced the number of buffer overflow problems in open source programs, according to several sources, including CERT, buffer overflows still account for at least a quarter of all security advisories, year after year.
Open source proponents sometimes claim that the “many eyeballs” phenomenon prevents Trojan horses from being introduced in open source software.
The speed with which the TCP wrappers Trojan was discovered in early 1999 is sometimes cited as supporting evidence.
This too can lull the open source movement into a false sense of security, however, since the TCP wrappers Trojan is not a good example of a truly stealthy Trojan horse: the code was glaringly out of place and obviously put there for malicious purposes only.
It was as if the original Trojan horse had been wheeled into Troy with a sign attached that said, “I’ve got an army in my belly!”
Well-crafted Trojans are quite different. They generally look like ordinary bugs with security implications, and are very subtle.
Take, for example, wu-ftpd. Who is to say that one of the buffer overflows that have been found recently was not a Trojan horse introduced years ago when the distribution site was hacked?
The open source movement hasn’t made the problem of buffer overflows go away.
But eventually, newer programming languages may; unlike C, modern programming languages like Java or Python never have buffer overflow problems, because they do automatic bounds checking on array accesses.
As with any technology, fixing the root of the problem is far more effective than any ad hoc solution.
Is Closed Source Any More Secure?
Critics of open source software might say that providing source code makes the job of the malicious attacker easier.
If only a binary is available, the bar has been raised high enough to send most such people looking for lower-hanging fruit.
But as the many well-publicized security holes in commercial software make clear, attackers can find problems without the source code; it just takes longer.
From a security point of view, the advantages of having the source code available for everyone to see far outweighs any benefit hackers may gain.
There are many benefits of open source software unrelated to security. And the “many eyeballs” effect does have the potential to make open source software more secure than proprietary systems.
Currently, however, the benefits open source provides in terms of security are vastly overrated, because there isn’t as much high-quality auditing as people believe, and because many security problems are much more difficult to find than people realize.
Open source programs which appeal to a limited audience are particularly at risk, because of the smaller number of eyeballs looking at the code.
But all open source software is vulnerable, and the open source movement can only benefit by paying more attention to security.
1. The Mailman Web site.
2. The ITS4 security scanner for C code.
3. Software security for developers.
4. The CERT Web site.