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

81–90 of 164 posts

Re: 15 years later: remote code execution in qmail

#81

Post by mcguire »

linsomniac wrote: post #35
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.…

Obvious Philosophy of Mind question of the day: What is the difference between a brain chemistry artifact and being an asshole for assholes sake?

Re: 15 years later: remote code execution in qmail

#82

Post by loup-vaillant »

smokecab wrote: post #67
mmm_grayons wrote: post #30

This 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.

Your prejudice against out-of-fashion software is unfounded. Qmail had a bug because qmail had a bug, not because it hasn't been rewritten in the past week. The major web browsers, for example, are all under very active development, yet new RCE (!) bugs are regularly introduced into them.

The bug was known 15 years back, and not fixed.

Re: 15 years later: remote code execution in qmail

#83

Post by derefr »

kevincox wrote: post #37
jstimpfle wrote: post #33

Earlier quoted context omitted.

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()

I mean, what other semantics would anyone expect it to have—presuming they think for a moment about why it exists as its own thing in the first place?

Re: 15 years later: remote code execution in qmail

#84

Post by kbenson »

rurban wrote: post #63
kbenson wrote: post #59

Earlier quoted context omitted.

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

Well, he used it with memory limits command line switches, so it could never be exploited. So he was technically correct. One should not use so much memory for a mail server, way too risky. Problem is, these switches were not default, people didnt use it because they are dumb, and DJB never cared to properly maintain it. like limiting memory per default, 32bit only builds or such.

> Problem is, these switches were not default, people didnt use it because they are dumb

Pushing complexity from a very small group (in this case, one person) who knows the system intimately to many orders of magnitude more people that are meant to have a functional knowledge of how it operates but not necessarily be intimate with it is a losing proposition, and not any tenet of how I would consider developing secure software.

If the software is only supposed to be run under process limits, and over a specific process limit all bets are off security wise, then the program should probably check and report problems with large process limits when it starts. Or, as you posit, dying if built for 64 bit, since its assumptions don't necessarily hold.

Re: 15 years later: remote code execution in qmail

#85

Post by derefr »

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.

I presume that a DJB-minus-ego wouldn't have had any motivation to become DJB in the first place ;)

Re: 15 years later: remote code execution in qmail

#86

Post by loup-vaillant »

im3w1l wrote: post #71
gowld wrote: post #55

Earlier quoted context omitted.

It's been 20 years; I don't think he's concerned.

Ahhh I see now that "qmail last had an official release in the late 90's". That changes everything, obviously.

In case it wasn't sarcasm: I would say it does not. What would, would be a note on the website explicitly mentioning that Qmail is unmaintained, and people should either take over maintenance or use something else.

Seeing no such disclaimer at https://cr.yp.to/qmail.html means DJB is (possibly unintentionally) still vouching for it. Right now in 2020.

Re: 15 years later: remote code execution in qmail

#87

Post by reaperducer »

cadence- wrote: post #68
vinay_ys wrote: post #46

Earlier quoted context omitted.

http://cr.yp.to/talks/2007.11.02/slides.pdf I don't see ego in these slides. I see a brilliant programmer acknowledging his mistakes and learning from them. I really enjoyed running qmail in early 2000s and following djb's crypto work later. He is brilliant indeed.

You should read some of his public.... ekhm... “discussions” with Wietse Venema on various security forums in the 90’s. It was very entertaining, but also clearly showcasing djb’s huge ego.

A lot of it would get you banned from HN and similar fora today.

Re: 15 years later: remote code execution in qmail

#88

Post by pwdisswordfish2 »

loup-vaillant wrote: post #77
pwdisswordfish2 wrote: post #66

"Finally, we also discovered two minor vulnerabilities in qmail-verify (a third-party qmail patch that is included in, for example, Debian's qmail package): CVE-2020-3811 (a mail-address verification bypass), and CVE-2020-3812 (a local information disclosure)." The vulnerabilities were introduced in a third party patch, not source code that was authored or advocated by djb. "As recommended by Daniel J. Bernstein, qma…

> The vulnerabilities were introduced in a third party patch Which patch are you talking about? I don't see anything about a patch in the CVE. > Seems much simpler than patching, let alone trusting someone else's patches. We can patch the issue for good (and with a simple patch, apparently), or we can rely on users not to mess with seemingly unrelated init scripts. Do you trust third party users more than a (likely h…

qmail-verify. It is an "update" of the third party "realrcptto" patch by another third party. It says "third party patch" right there in the sentence I quoted. There is no qmail-verify in original qmail.

As to the second question, I trust softlimit from daemontools and that is what I use. https://cr.yp.to/daemontools/softlimit.html

Not sure what "messing with seemingly unrelated init scripts" means. Can you be more specific?

Re: 15 years later: remote code execution in qmail

#89

Post by kstrauser »

derefr wrote: post #85
kstrauser wrote: post #25

Earlier quoted context omitted.

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.

I presume that a DJB-minus-ego wouldn't have had any motivation to become DJB in the first place ;)

Oh, I don't know about that. There are lots of brilliant computer scientists and mathematicians with reputations for also being really nice and humble people. The smartest people I know freely admit when they're at the edge of their knowledge and abilities, and are the first to tell you when they've made mistakes.

Re: 15 years later: remote code execution in qmail

#90

Post by derefr »

kstrauser wrote: post #89
derefr wrote: post #85

Earlier quoted context omitted.

I presume that a DJB-minus-ego wouldn't have had any motivation to become DJB in the first place ;)

Oh, I don't know about that. There are lots of brilliant computer scientists and mathematicians with reputations for also being really nice and humble people. The smartest people I know freely admit when they're at the edge of their knowledge and abilities, and are the first to tell you when they've made mistakes.

You're talking about other people's motivations. But DJB minus ego wouldn't be some other person, he'd still be DJB; just "DJB if you cut a certain part of his brain out." And I don't think that that person would have any other motivation-generating part of his brain left. His works specifically seem entirely ego-driven. DJB minus the ego probably wouldn't have had any interest in becoming an information-worker at all. (I'd like to think he'd become a janitor, like the protagonist of Flowers for Algernon. :P)
Post reply on HN