OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
On product vulnerability history and vulnerability complexity

From: Steven M. Christey (coleymitre.org)
Date: Fri Mar 24 2006 - 02:01:32 CST


Gadi Evron said:

>"Hey mom, what's my root password? I forgot"
>"Dunno, just use the new sendmail vulnerability!"

The fact that a product has a long history of bugs should not be
regarded as an indicator of its current level of security compared to
other products.

I've been of the mindset lately that one should look at (1) how
extensively a piece of software has been audited, (2) by whom, and (3)
the complexity of any associated vulnerabilities and attacks. If you
look at recent Sendmail holes, they are complex and not immediately
obvious. Some years ago, Michal Zalewski had to invent the signal
handler race condition vulnerability class (CVE-2001-1349) which is
probably latent in many products, but rarely audited. ISS had to
perform some non-standard syntactic manipulations involving large
numbers of special characters (CVE-2002-1337 [sic]). More recently
announced Sendmail issues have not been much simpler.

I suspect that the complexity of discovered vulnerabilities *means*
something about the relative security of software, compared to your
normal piece of SMTP software that barfs on 100 "A" characters in the
RCPT TO command, let alone your software with the standard XSS or SQL
injection.

Let's not forget how Georgi Guninski in 2005 found a rather obscure
security issue in qmail itself. As I understand it, the exploit
involved consuming resources in the 1GB range, but still - there was a
bug. Is qmail immediately suspect now because it had an overflow, and
overflows have been known about for decades? No - the vuln and
exploit were rather complex, and found by one of the top researchers
in the industry, while showing that even the most respected developers
might not account for obscure architecture-dependent issues that were
probably buried deep in include files.

And to beat a horse long thought dead, people thought that non-IE
browsers were so secure a couple years ago, but researchers are taking
a look at non-IE browsers, and they're not quite so bug-proof as
previously assumed. I forget where I saw this, but very recently
someone said "this browser bug was fixed in IE a couple years ago."

One difficulty is that we can't really know a product's full audit
history. If a researcher looks at a piece of software and finds
nothing of interest, that doesn't get reported. (Sardonix, we hardly
knew ye.)

It seems counterintuitive, but I'm immediately suspicious of any
software that doesn't have a well-documented history of security
vulnerabilities that show increasing complexity and novelty as the
product matures. Darwin's theory of evolution might well hold for
software security.

- Steve

P.S. If you're interested in investigating vulnerability complexity,
feel free to contact me. I have a couple pages of notes and tendrils
of a taxonomy, but nothing formal yet.