Here is a not-quite recent article regarding one of the very products illustrated for this discussion, and an issue over a 'security vulnerability'. Take it as you will, but I think it defends the position catch has taken.Quote:
Originally posted here by catch
Without formal V&V a "secure" software product is little more than assumptions:
I assume this product the type of security I need.
I assume that the implicit rules have been sufficiently tested.
I assume that there exists no ways to take advantage of flaws that I don't know about.
Link to full article.
I felt it was important to point this out to you all. Dan does not feel inclined to acknowledge this as a threat. Jason (that author) clearly feels it is a valid vulnerability, regardless of likelihood of exploitation. At what point does a threat become an "official" vulnerability? And by whose voice/hand?Quote:
...<snipped and paraphrased, my apologies to Jason Miller>...
(Dan) 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
...<snipped>...
I don't have the answers, I'm just throwing this in to stir things up^U^U^U see what you all think. ;) I do think that Jason's message, in closing the article, was paramount, even though his position may be opposite of catch's. 'Practice' is more important than 'polish'.
