That's quite interesting because the bug was there and was quite clear, and was not fixed by one of the most brilliant security persons out there (DJB). Maybe here the attitude really was the wrong one, considering how security oriented qmail was since the start, because the simplest possible fix does not seem to demand any other dimension, like complexity or performances.
15 years later: remote code execution in qmail
51–60 of 164 posts
Re: 15 years later: remote code execution in qmail
#52I would bet a lot of upvotes on this come from people misreading this as Gmail as I did :)
No. I ran several Qmails for many years on Mandrake with daemontools to supervise. All compiled from source. Lovely. "Life with Qmail" is a classic.
I needed some additional flexibility and switched to Exim for my MTA of choice instead but have fond memories of Qmail.
Re: 15 years later: remote code execution in qmail
#53Earlier quoted context omitted.
Yeah, it was denied. About our new discovery, Daniel J. Bernstein issues the following statement: "https://cr.yp.to/qmail/guarantee.html has for many years mentioned qmail's assumption that allocated array lengths fit comfortably into 32 bits. I run each qmail service under softlimit -m12345678, and I recommend the same for other installations." And from his "guarantee" In May 2005, Georgi Guninski claimed that some…
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?
The app is vulnerable if it runs in an unsafe environment that allows qmail to access more than 4GB (an absurdly large value when qmail was published in 1997 -- it would cost $5000 plus a rare, expensive machine to hold it).
djb's view is that the environment is the responsibility of the admin, not the program's responsibility to enforce sane defaults. This is of course debatable.
If the admin uses a recommended environment (low memory limit), there is no exploitability.
Re: 15 years later: remote code execution in qmail
#54Re: 15 years later: remote code execution in qmail
#55Earlier quoted context omitted.
My guess is that he'd never accept it. He originally didn't allow people to distribute qmail with changes; this is squarely a Debian issue.
If he takes that stance than it will cast doubt on everything else he has done. If there is a footgun on the wall, by the end it must go off, and chaining "non-exploitable" bugs together is routine stuff for hackers.
It's been 20 years; I don't think he's concerned.
Re: 15 years later: remote code execution in qmail
#56Earlier quoted context omitted.
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…
If we could tell a priori which unreachable cases were reachable it wouldn't be such a problem. Asserting only in debug builds is rather ineffective because the unthinkable input isn't in your testsuite. If it were, then it wouldn't have been unthinkable.
> Asserting only in debug builds
Right, but I am also suggesting another approach: if you have a large fleet of machines or a client app with a lot of usage, you can enable it in a small percentage of runs and if it hits in the wild you still have a chance of learning about it, without tearing down the process for all users. I have seen that strategy be effective.
Very hard to know which behavior is appropriate in advance though. An assert that turns out to represent a benign circumstance that is already handled, multiplied by large numbers of machines, can be pretty annoying.
Re: 15 years later: remote code execution in qmail
#57The 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.
4GB was impossible when qmail was last updated.
Re: 15 years later: remote code execution in qmail
#58DJB 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.
I once was talking to one of the household-name DNS guys and asked what he thought about djbdns and he said something along the lines of: "It's unfortunate that he's so abrasive, because he has some really great ideas that nobody will listen to because of it." I've more recently come a little bit to terms with this whole abrasive thing being a brain chemistry artifact, and not just being an asshole for assholes sake.…
LPT: take a shortcuts to success by listening to djb and plagiarzing his ideas.
Re: 15 years later: remote code execution in qmail
#59Earlier quoted context omitted.
It's not "they", it's Daniel J. Bernstein. That's the reason :) (If you don't know: he is a top cryptographer that can amazingly correct code. However, he also has a very big ego...)
I don't understand. Most people with a big ego would not want a critical vulnerability associated with them. Can you elaborate?
he had such confidence in his software and abilities that he thought it was actually secure, and there were no bugs, and posted a bounty for any exploit that could be found. Patching it means acknowledging it's an exploit, and that his code was not without bugs.
Given that his principles of writing secure software (included in the Qmail guarantee[1]) includes this: "7. Write bug-free code." that might be a bit hard for him to swallow.
Re: 15 years later: remote code execution in qmail
#60Serious 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…
Can you give an example of a claim he "welched" on? Google isn't pointing me to anything except the fact that email is unencrypted which I tend to agree is out of scope.