A role model for security. Almost., 2005-06-08
Story continued from Page 1
“
If the information security industry is creating this kind of environment for developers, then we're doing something wrong.
”
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.
