Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

15 years later: remote code execution in qmail

qualys.com

Post reply on HN
Print view View original

31–40 of 164 posts

Re: 15 years later: remote code execution in qmail

#31

Post by neonate »

kstrauser wrote: post #25
arbitrage wrote: post #23

Earlier quoted context omitted.

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.

But that DJB doesn't exist. I can come up with much bigger losses if they don't have to exist.

Re: 15 years later: remote code execution in qmail

#32

Post by kstrauser »

asveikau wrote: post #26
bluejekyll wrote: post #3

Earlier quoted context omitted.

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…

I didn't downvote you and I interpreted your comment the way you said you meant it. I do happen to disagree, though.

For a project in a space that's notoriously vulnerability prone - I mean, when it was released it was competing with Sendmail - it seems very reasonably cautious to pepper the code with panic handlers in "impossible" places. They won't slow the code down any because they should never be evaluated, but give nice, noisy explosions when unexpected things happen. There's no downside to doing this.

Re: 15 years later: remote code execution in qmail

#34

Post by jstimpfle »

pvarangot wrote: post #27
kevincox wrote: post #22

Earlier quoted context omitted.

If you are really sure put __builtin_unreachable()

I'm pretty sure he didn't have that on most of the platforms he was targeting with his portable C code, it's not even there on some of them now.

what you do is you define a macro in a common header. Like UNREACHABLE().

Re: 15 years later: remote code execution in qmail

#35

Post by linsomniac »

jedberg wrote: post #24

DJB 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. Because it seems to disproportionately impact those of us in the technical field. Not to excuse it, but to understand it.

Re: 15 years later: remote code execution in qmail

#36

Post by linsomniac »

arbitrage wrote: post #23
DominoTree wrote: post #6

Serious 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…

So wide-spread is his ego, that it reminds me of this quote from Donnie J. Barnes (of RedHat): "I went on IRC once. I was mistaken for Dan Bernstein. I still have nightmares."

Re: 15 years later: remote code execution in qmail

#37

Post by kevincox »

jstimpfle wrote: post #33
kevincox wrote: post #22

Earlier quoted context omitted.

If you are really sure put __builtin_unreachable()

Shoot I have done that in the past but it seems I actually wanted __builtin_trap().

Yeah, that footgun should really have a more explicit name.

__dear_compiler_i_promise_that_this_statement_is_unreachable_and_you_may_optimize_based_on_my_good_word_upon_penalty_of_undefined_behaviour()

Re: 15 years later: remote code execution in qmail

#38

Post by icedchai »

allover wrote: post #15
friday99 wrote: post #13

Earlier 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?

qmail last had an official release in the late 90's. everything else is third-party forks / patches. Back in the day, I upgraded many systems from sendmail to qmail. However, that was a very long time ago... It's been over 15 years since I've done something like that.

Nowadays, the author should be telling people to install postfix.

Re: 15 years later: remote code execution in qmail

#39

Post by dsl »

arbitrage wrote: post #23
DominoTree wrote: post #6

Serious 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…

DJB paid out $1,000 in 2009 to Matthew Dempsky for a djbdns security vulnerability.

https://marc.info/?l=djbdns&m=123613000920446&w=2

Re: 15 years later: remote code execution in qmail

#40

Post by tedunangst »

asveikau wrote: post #26
bluejekyll wrote: post #3

Earlier quoted context omitted.

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…

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.

Post reply on HN