The surprising thing here for me was that you can send qmail a 4GB email message and it will not immediately reject it in the default configuration.
15 years later: remote code execution in qmail
21–30 of 164 posts
Re: 15 years later: remote code execution in qmail
#22Re: 15 years later: remote code execution in qmail
#23Serious question: Was there a legitimate reason they didn't patch this stuff when it was first discovered?
The original qMail author, Dan Berstein (DJB) was so convinced of the infallibility of his code that he put up a monetary reward for any exploits. This context came about because DJB, as a professor of Computer Science, maintained that it is completely within the realm of reality to write unbuggy, yet complicated and highly functional code.
DJB welched on every claim at that bounty, and refused to pay out. He is an egotistical over-selfconfident person. He wrote good code back in the day, but he lost the forest for the trees.
Re: 15 years later: remote code execution in qmail
#24DJB makes great code, but it always leaves a sour taste to use his code, because he has such a big ego and refuses to admit when he makes a mistake. He can't admit that it's possible to be the best but still make mistakes.
I really hate supporting that.
Re: 15 years later: remote code execution in qmail
#25Serious question: Was there a legitimate reason they didn't patch this stuff when it was first discovered?
The original qMail author, Dan Berstein (DJB) was so convinced of the infallibility of his code that he put up a monetary reward for any exploits. This context came about because DJB, as a professor of Computer Science, maintained that it is completely within the realm of reality to write unbuggy, yet complicated and highly functional code. DJB welched on every claim at that bounty, and refused to pay out. He is an e…
You're being downvoted, but from what I can tell you're right. DJB is undoubtedly a brilliant computer scientist, but it seems he'd be very quick to tell you that. I see this as a loss to our profession because I think that DJB-minus-ego could make even more awesome things.
Re: 15 years later: remote code execution in qmail
#26Oh, dear. Another "will never happen" issue which, after not so long (in the history of mankind) takes place. And this one would not have been so complicated to fix (just enforce a limit as the author suggests). /* this line is unreachable */ printf("You have reached unreachable code\n"); 10 years later, it gets printed...
Why not exit/panic at that point? Seems like the right thing for any “unreachable” code.
I could see an argument (similar to for assert()) to omit such a check in most production builds. Maybe you could enable it for a small amount of hosts, so that if it does happen with any frequency, somebody sees it somewhere.
But not every "unthinkable" case being reached represents a security problem as it does in this case. So in the general case of how to approach such assert-type checks, an abort might take down the process when not necessary, turning it into a DoS.
Edit: I am not sure if my friend the downvoter realizes I am not trying to justify legit security bugs, just talking abstractly about varying approaches to handling asserts for unforeseen or "allegedly impossible" circumstances.
Re: 15 years later: remote code execution in qmail
#27Re: 15 years later: remote code execution in qmail
#28Earlier quoted context omitted.
What did Debian change to introduce this vulnerability?
Nothing, per se. But they don't set up softlimits or message size limits by default, both of which you should definitely do... it's just that the values you put in are specific to your situation.
If you have DJB's ego yelling at you that the default configuration is safe, why would you bother setting limits to fix it?
Re: 15 years later: remote code execution in qmail
#29Earlier quoted context omitted.
So the app is vulnerable by default, yet the author is claiming this doesn't matter, because he instructs how to run it in a safe way? Correct, or am I oversimplifying/missing something?
Maybe add a reference to how ElasticSearch (or some other new-pop tech) catches heck for the same?
I think you're being downvoted because other things being insecure is not relevant or an excuse.
Re: 15 years later: remote code execution in qmail
#30This is why you don't run software that fossilized back in the nineties. Qmail was solid code but hasn't received the support and on-going development it needed. Use postfix instead for a secure MTA.