There's an old adage that goes something along the lines of, "if it ain't broke, don't fix it." This is a paradigm that's often ignored in the software industry. For better or for worse, a large portion of the software that we use is constantly being changed. Features are being added, code is being polished or optimized, bugs are being fixed, and as such many programs are in a continuous state of development. Naturally, this has security implications whenever something is changed or added.
That being said, there are a few notable projects that have made stable releases, and solidified their feature list and code base. Qmail, for example, doesn't really change. Although the qmail source tree, with all of its patches and add-ons, isn't the most user-friendly thing to obtain, customize, compile, and install, qmail is considered to be one of the more securely designed and written applications. Notwithstanding the fact that qmail was designed from the ground up to be a secure application, the fact that the qmail source tree is mature and unscathed by continuous feature creep and code modification undoubtedly contributes to it's solid reputation.
If writing secure software is difficult, is modifying that software any less prone to security blunders? Of course not. Features are great, but we need to remember that by adding code to an existing project, we will affect the maturity of the code base. Although the maturity of any given code doesn't necessarily guarantee additional security, I do think that mature code is on the average "more secure" than new code. Regardless, having feature rich bleeding edge software is important for some people, while other people (myself included) prefer an
older, more mature code base. The beauty of open source software is that everyone can choose which blend of the two (features and code maturity) suits them best.
Small changes lead to a big vulnerability
Recently, a vulnerability in ZLib was discovered by Tavis Ormandy, a member of the Gentoo Linux Security Audit Team. ZLib is a general purpose compression library, and is about as pervasive as open source libraries get. It's included in CVS, Gzip, TightVNC, Firefox, and OpenSSH, just to name a few of the particularly significant and easily recognizable ones.
Although the library has been in use for quite some time, it is still being actively developed and maintained. Recent changes to the code base introduced this vulnerability, exposing a large number of applications to attack and potentially compromise. Aside from the large number of applications that are affected by this issue, the idea of a vulnerability in a widely used open source library brings up some pretty interesting concerns.
Firstly, we know that multiple applications are affected by this issue. Although this might seem like a really bad thing, it isn't. Instead of having several desperate implementations of zlib, some of which may have been vulnerable to a similar attack via a distinct bug in a separate code base, we have a single vulnerability that can be fixed in one code base, and this can instantly address the issue everywhere at the same time. In other words, the fact that this issue affects so many applications does have some saving grace. It means that the issue can be addressed swiftly, and many people will benefit from the discovery and patching of the bug. This is a really interesting trait of open source software that you won't find in world of closed source software.
This open source code centralization benefits attackers and defenders alike. On the attacking side, libraries like zlib should be important targets for attacks, as the discovery of bugs in a library such as this gives an attacker a very large base of vulnerable targets. On the defending side, however, this single implementation will continue to grow, strengthen and mature, providing a plethora of applications with a solid compression library. It's certainly an interesting quirk of open source software.
Now, whether or not this vulnerability is exploitable for something other than a Denial of Service (DoS) attack is still under debate, but in my experience, you can often break up vulnerabilities such as these into into two categories: those that can be exploited, and those that can't be exploited yet. You should almost never assume otherwise - the Apache Chunked-Encoding Memory Corruption Vulnerability, for example, should serve as a strong reminder to those who believe otherwise.
Regardless of the specific software that you use, if you're an avid reader of the Unix focus area, you're probably affected by this vulnerability in some way or another. Do yourself a favor and make sure that you've taken the time to address this vulnerability on any systems or in any applications that you maintain. This bug is so pervasive that your exposure to attack is far greater than you might believe, and the implications of successful exploitation are nothing short of significant. I don't know about the rest of you, but there's nothing more frightening for me than the possibility of pre-authentication vulnerabilities in OpenSSH.
It never hurts to be paranoid. When addressing something as widespread as the Zlib Compression Library Buffer Overflow Vulnerability, it could really hurt not to be.