,
Mark Burnett beat me to it. I was planning to write an article on the relationship between good security and paranoia in the not too distant future. However, it appears that at least one other SecurityFocus columnist shares some of my theories on good security. Either that, or he's somehow capable of reading my mind. Paranoia is generally a good thing to have. Regardless, Mark's article got me wondering about what other traits are valuable in the quest for good security.
The pursuit of absolute security is a lot like perfectionism. Both are unattainable and the task of pursuing them is itself a never-ending process, a determined quest for a goal that can never be realized. The fact that perfection cannot be achieved does not prevent a perfectionist from attempting to find it, however. Likewise, the fact that absolute security is an impossibility won't stop a good security professional from trying to achieve it. Simply put, there is never a point where a good security professional says that a network is so secure that it doesn't require improvement.Qmail's pursuit of perfection
If we think about applications with a relatively "perfect" (I use the term very loosely) security track record, not many come to mind. However, I'd be willing to bet that software written by Dan Bernstein, specifically qmail (and djbdns), might be first among those mentioned. Why is qmail considered secure? There are two main reasons.
Bernstein designed qmail with security in mind. If everyone who wrote software actually made security a design priority, we'd be in a lot less trouble with vulnerabilities than we are now. But it appears this is too much to ask, because there's so much software out there that doesn't seem to put much more than a casual afterthought into security.
Secondly, Bernstein strives to write bug-free code. Although this is an unachievable goal, it didn't stop Bernstein from trying. His code has now stood the test of time, and has done so with a very small security vulnerability footprint.
The combination of these two factors has made qmail a very successful application for secure environments.
Qmail isn't perfect
Georgi Guninski recently published a vulnerability in qmail (albeit not a practical one), which can be exploited on specific configurations of some 64-bit systems. That's right. Even qmail has bugs. This shouldn't be a surprise to anybody.
If you're familiar with qmail, you'll undoubtedly be aware of the qmail security guarantee, which offers a monetary reward to the first person to publish a "verifiable security hole in the latest version of qmail". Bernstein has publicly denied this reward to Guninski, with the statement that "Nobody gives gigabytes of memory to each qmail-smtpd process, so there is no problem with qmail's assumption that allocated array lengths fit comfortably into 32 bits." This basically means that Bernstein doesn't consider this to be a security vulnerability.
Despite the fact that the vulnerability may have only academic merit -- it doesn't seem very likely that this will be exploited in the wild -- it is still a security vulnerability. As far as I'm concerned, the offending code should be fixed. I don't care how circumstantial it is; not fixing the issue accomplishes nothing.
The fact that software developers feel the need to maintain some sort of "clean record" that might be more important than tidying up even potentially vulnerable code, is quite disturbing to me. If the information security industry is creating this kind of environment for developers, then we're doing something wrong.
A clean record counts for nothing
Ultimately, when vulnerabilities are discovered in software, it does not necessarily mean that the author of the software was negligent. It seems as though we have developed a theory that vulnerabilities shouldn't exist, and that any vulnerabilities that do exist are the fault of the author. Sure, there is no excuse for poor and insecure code, but no one is perfect.
When obscure issues such as the qmail vulnerability are discovered, it doesn't make any sense to sweep the issue under the digital rug, and deny its potential implications, no matter how inconsequential or circumstantial they may be. In this case, it seems as though the "security guarantee" and the reputation of the software are on the line, because acknowledging the issue and patching it might be akin to admitting defeat. This doesn't seem like the right way to handle the problem. It does seem to indicate, however, that the monetary reward might be counter productive to its goal.
We should strive to make software perfect, but shouldn't be surprised when someone points out that it isn't. If there was no reward for finding security vulnerabilities in qmail, and no one was concerned with the need to keep a "clean record," then we could just fix the issue and be done with it.
Take care of your code, and your image will follow
Don't worry about maintaining an image of perfection. Just strive for perfection, and your image will take care of itself. If Bernstein decides to patch the Guninski issue, it won't tarnish my view of qmail's outstanding commitment to security, not in the slightest. In fact, I think patching the issue, despite the impractical nature of exploitation, would do quite the opposite.
Besides, a security professional can tell the difference between a theoretical bug in an exceptional application, and an embarrassing bug in an application that treats security as nothing more than a marketing buzzword.
Ultimately, when I look at the history of vulnerabilities in an application, issues like this one make me feel warm and fuzzy inside. When a talented vulnerability researcher such as Guninski publishes this issue, there's a good chance that he payed close attention to the rest of the code. If this is all that he was able to find, then lets patch it and take one more step towards perfection.
Many developers could still learn a thing or two from Bernstein and qmail. His strive for perfection and the track record of qmail, even despite this current issue, has been admirable. It seems that at their very outset, however, there are still very few developers who will develop their software with similar security goals in mind.