Slashdot Mirror

Regarding qmail not having any security flaws, and there being no takers on the $500, that is not strictly true:

http://www.jcb-sc.com/qmail/guninski.html

djb has refused to give the $500, but that is merely another symptom of his Jupiter-sized ego distorting reality.

GC makes it easier. People can still screw up, but you are doing away with an entire class of too common mistakes.

Using C is just like driving a manual without a clutch. It can be done, you just need to concentrate. One mistake and poof. So far there appear to be only a handful of people in the entire world who can write safe C. So far Dan Bernstein appears to write reasonably safe C and even he makes some mistakes ( http://www.jcb-sc.com/qmail/guninski.html )...

Using Java/C# is like driving an automatic. And advanced "JIT" VMs are like those new high performance automatic transmissions - they can do better than most humans AND more importantly they are more consistent and reliable when doing it.

FWIW, I wonder why it is common to push data onto an address stack. To me address = code. Mixing data and code ( addresses ) is bad hygiene. You should only do it in controlled circumstances, not as a norm. Why can't you have separate stacks? While there will still be problems, it will make certain bugs harder to exploit.

Only because DJB won't honor it. People have found bugs in his code, but he refuses to acknowlege them.

As my page (to which you link) notes, these bugs are likely exploitable only in theory.

And I've been hired (and paid well) to modify qmail code, including patching it to fix bugs as well as extending it, for years now, but nobody has even inquired as to what it'd take to fix the "Guninski" bugs that might theoretically be exploitable — at least, not so far.

I think that's a pretty sure indication that the qmail user base does not consider those bugs to be sufficiently worrisome to fix. (I did publish a simple fix to one of the first bugs Guninski found; that fix was incorporated into netqmail. But I did that gratis.)

I don't know offhand whether DJB has ever acknowledged any bugs in qmail. But, just as code doesn't lie while comments can, code that is reasonably well-specified, as qmail's components' interfaces are, cannot pretend bugs don't exist in it, even if authors or fanboys do, just as it can't pretend it has bugs even when claimed otherwise[*]. So I don't particularly miss djb's opinions and pronouncements on such issues, since I can read the code and decide for myself.

[*] There's a web page out there that claims "qmail-smtpd does not detect CR LF properly on packet boundaries", which strikes me as complete and utter — as well as easily demonstrable, by simply looking at the code — nonsense. Not that it can't happen, but it'd almost certainly be due to an OS, networking, or (non-qmail) library bug. Tellingly, despite the high likelihood such a bug would result in huge numbers of legitimate emails being rejected by many qmail servers worldwide, there's no information on this alleged bug beyond somebody supposedly reporting it. That's only marginally more persuasive than saying "qmail-smtpd dropped every third email on every server running it on March 17, 2001, between 11:45 and 12:15 UTC, according to a guy I overheard in a bar the other day." Color me unimpressed.

I agree — SPF is not a silver bullet, and using it is probably unwise, though publishing SPF records (other than just "?all") for those who insist on using it seems reasonable to me.

I must admit, it's sad to see that Dan hasn't patched the qmail-smtpd portability problem. I don't think you can call it anything but a bug.

If it's a vulnerability, it's a *very* unlikely one, for the simple reason that almost no configuration on earth gives a single qmail-smtpd 2GB+ of memory.

But it is a bug, and I agree it (and similar bugs) should be fixed in an official release of qmail (not just a patch, which is what netqmail is).

Note that I wrote the web page, to which I link above and to which the GP linked, about ten months ago, and it has been widely read and linked to. But nobody has yet seen fit to hire me (or even request of me as a volunteer!) to fix the pertinent bugs, nor have I bothered to do so myself!

I think that's consistent with your impression of qmail, security-wise: people who really look at the big picture realize that complaining about qmail's "vulnerabilites" is, at best, a waste of breath; nobody wants to also waste money on trying to "solve" non-problems.

http://www.jcb-sc.com/qmail/guninski.html
http://secunia.com/advisories/10649/
http://secunia.com/advisories/15533/
http://www.frsirt.com/english/advisories/2005/0490
http://www.frsirt.com/english/product/3207
http://www.saintcorporation.com/cgi-bin/demo_full_ tut.pl?tutorial_name=Qmail_vulnerabilities.html&fa ct_color=doc&tag=