qmail Author Considered Dangerous
Thanks to LWN I was reminded of the, erm, interesting license and security guarantee of qmail. Specifically:
In March 1997, I offered $500 to the first person to publish a verifiable security hole in the latest version of qmail: for example, a way for a user to exploit qmail to take over another account. My offer still stands. Nobody has found any security holes in qmail. [...] In May 2005, Georgi Guninski claimed that some potential 64-bit portability problems allowed a ``remote exploit in qmail-smtpd.'' This claim is denied. 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.
Erm. Well. I'm not sure what to say. Assuming that array lengths (size_t, IIRC) is a 32-bit type even on 64-bit architectures is wrong. Defending it is insanity.
NP: Layered, Antibreak
Posted by Daniel at Thu Aug 31 16:00:07 2006:
He offered $500 to find a security hole. It took eight years for someone to make a plausible claim. You're dismissing him as both dangerous and insane, misrepresenting what he wrote and putting something about crack in there as well. While listening to prog.
Posted by Ross at Thu Aug 31 16:08:27 2006:
Yes, to be fair the source must be pretty solid to last that long. But denying the advances of 64-bit computing... madness.
Posted by BenjaminDauvergne at Thu Aug 31 16:18:58 2006:
I think you don't understand neither the comment by Bernstein neither the bug found by Guninski.
Bernsteing said that well administered smtp process have resource limit so they never reach 1Gb of data segment, even on a 64bit architecture. (there is no use to handle 1Gb emails).
Posted by Ross at Thu Aug 31 16:34:11 2006:
Bernsteing said that well administered smtp process have resource limit so they never reach 1Gb of data segment, even on a 64bit architecture. (there is no use to handle 1Gb emails).
So if qmail is so great how come it can be exploited with a 1GB email, when it should cleanly refuse to handle the mail as it is too big.
Also, I may have some insane plan that involves sending 1GB emails: say I work in the movie industry. I'd prefer to use a MTA that either sent it fine or refused to send it as it's too large, not one that crashed unless I set a separate set of resource limits.
From the web page I link to: "The stralloc concept and getln() make it very easy to avoid buffer overruns, memory leaks, and artificial line length limits.". This appears to be failing if a large email can crash qmail.
Posted by Russell Nelson at Thu Aug 31 17:37:44 2006:
Also, I may have some insane plan that involves sending 1GB emails: say I work in the movie industry. I'd prefer to use a MTA that either sent it fine or refused to send it as it's too large, not one that crashed unless I set a separate set of resource limits.
From the web page I link to: "The stralloc concept and getln() make it very easy to avoid buffer overruns, memory leaks, and artificial line length limits.". This appears to be failing if a large email can crash qmail.
You misread djb's rejection of Guninski's claim. He doesn't suggest that qmail only works with a 32-bit size_t. He suggests that no sane sysadmin will give a qmail process a high enough limit to exceed 32-bit ints.
djb's larger point is that it's not safe to assume that your programs will catch every resource exhaustion attack, thus every long-running process should run under resource limits imposed by the kernel.
Posted by HE at Thu Aug 31 18:18:47 2006:
Posted by Ken at Thu Aug 31 19:45:53 2006:
djb's larger point is that it's not safe to assume that your programs will catch every resource exhaustion attack, thus every long-running process should run under resource limits imposed by the kernel.
I hope this trend doesn't take off:
- free software developer offers $$$ if you find a bug
- person finds a bug
- developer refuses to acknowledge it to save $$$
What if I found an exploit if you sent a particular byte? Would the response be "well, any sane sysadmin would install a packet filter to ...".
This seems like an isolated incident, but if it becomes common, at some point, a sane sysadmin will just switch to a MTA maintained by somebody who doesn't make excuses.
Posted by bisho at Thu Aug 31 20:49:56 2006:
- free software developer offers $$$ if you find a bug
- person finds a bug
- developer refuses to acknowledge it to save $$$
What if I found an exploit if you sent a particular byte? Would the response be "well, any sane sysadmin would install a packet filter to ...".
This seems like an isolated incident, but if it becomes common, at some point, a sane sysadmin will just switch to a MTA maintained by somebody who doesn't make excuses.
Qmail is NOT crashing with a 1Gb email!!!
The question here is that someone found some parts of the code that may have problems in 64 bit systems, as some arrays use only the 32 first part in his code.
On one hand it's true that if the size of the variable is 64 bit, it should be treated as 64 bits, no 32.
On the other hand the Qmail's author offered $500 to the first person who find an explotable bug. That remains to be seen if it's exploitable or not. Probably you won't be able to fill the 32 bit arrays before crushing the mailer first under the load.
Posted by bisho at Thu Aug 31 20:52:43 2006:
The question here is that someone found some parts of the code that may have problems in 64 bit systems, as some arrays use only the 32 first part in his code.
On one hand it's true that if the size of the variable is 64 bit, it should be treated as 64 bits, no 32.
On the other hand the Qmail's author offered $500 to the first person who find an explotable bug. That remains to be seen if it's exploitable or not. Probably you won't be able to fill the 32 bit arrays before crushing the mailer first under the load.
BTW, Qmail's author is a quite strange person. He always use his own methods for every program. A diferent way of starting, you could only distribute source code...
I don't like Qmail for its strange behaviors and particular way of doing all things. But his DNS tools are the best, tinydns and the like. Really good and nice to configure/mantain.
Posted by Marc at Fri Sep 1 09:48:17 2006:
I don't like Qmail for its strange behaviors and particular way of doing all things. But his DNS tools are the best, tinydns and the like. Really good and nice to configure/mantain.
To bisho:
"That remains to be seen if it's exploitable or not."
Guninski provided an exploit. Nothing left to be seen.
Posted by Jonas at Fri Sep 1 12:03:16 2006:
"That remains to be seen if it's exploitable or not."
Guninski provided an exploit. Nothing left to be seen.
Look, you are not being fair to DJB. If you dislike his manners you mustn't behave the same way. This guy actually wrote some email software withstanding nearly a decade of close scrutiny. He didn't even trust libc functions when writing it which makes his look very eccentric but history has proven him right.
The fact remains that IF you install qmail as per the documentation (granted, you have to read it very closely indeed), this hole is not exploitable. I would agree that the software should be fixed for aesthetics alone, but this is not what the security guarantee covers.
To be vulnerable, you would have to both compile it in a 64-bit environment AND avoid setting any size limitations.
If you configure your software to receieve 8 GB (!) emails, you're probably vulnerable to DoS attacks even when you've patched this hole.
Posted by Ross at Fri Sep 1 12:16:47 2006:
The fact remains that IF you install qmail as per the documentation (granted, you have to read it very closely indeed), this hole is not exploitable. I would agree that the software should be fixed for aesthetics alone, but this is not what the security guarantee covers.
To be vulnerable, you would have to both compile it in a 64-bit environment AND avoid setting any size limitations.
If you configure your software to receieve 8 GB (!) emails, you're probably vulnerable to DoS attacks even when you've patched this hole.
I'm not saying the code is terrible, obviously its generally solid as it's stood the test of time, and enough administrators put up with strange license and use it, so it's obviously got some appeal.
In a years time the majority of servers will be 64-bit, so your "to be vulnerable" statement comes down to "don't set size limitations". At the end of the day the bug is, as far as I know, "assume array lenghts are 32-bit", which is wrong. Very wrong. There is no way that is correct on a 64-bit machine. Fixing this would involve changing an "int" to a "long", or using the correct type, "size_t". This is a BUG. No matter how great the rest of qmail is, or how great his other software is, assuming array lengths are 32-bit is BROKEN. Refusing to acknowledge this by saying that you should have limitations preventing large emails isn't helpful.
In a years time the majority of servers will be 64-bit, so your "to be vulnerable" statement comes down to "don't set size limitations". At the end of the day the bug is, as far as I know, "assume array lenghts are 32-bit", which is wrong. Very wrong. There is no way that is correct on a 64-bit machine. Fixing this would involve changing an "int" to a "long", or using the correct type, "size_t". This is a BUG. No matter how great the rest of qmail is, or how great his other software is, assuming array lengths are 32-bit is BROKEN. Refusing to acknowledge this by saying that you should have limitations preventing large emails isn't helpful.
