Bugtraq mailing list archives
On product vulnerability history and vulnerability complexity
From: "Steven M. Christey" <coley () mitre org>
Date: Fri, 24 Mar 2006 03:01:32 -0500 (EST)
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.
Current thread:
- On product vulnerability history and vulnerability complexity Steven M. Christey (Mar 24)