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.
It is somewhat rare to find projects that make a stable release and
then discontinue development indefinitely. Even Blackbox (my window
manager of choice) was recently re-released after almost two years of
development limbo. After all, it's hard to look at any application
and be unable to come up with a list of improvements or additional
features that would make the software work better for you.
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.
Jason Miller manages the Focus IDS area for SecurityFocus and is a
threat analyst for Symantec Corporation.
---
* Origin: [adminz] tech, security, support (192:168/0.2)
generated by msg2page 0.06 on Jul 21, 2006 at 19:03:46
search: