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

61–70 of 164 posts

Re: 15 years later: remote code execution in qmail

#61

Post by allover »

gowld wrote: post #53
allover wrote: post #15

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

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

So it's not secure by default.

Re: 15 years later: remote code execution in qmail

#62

Post by rurban »

stevekemp wrote: post #20
dullgiulio wrote: post #10

Earlier 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...)

qmail was essentially unmaintained for a long time, people were distributing patches to it, but there were no upstream releases. (Similar story with djbdns/tinydns.) "Recently" he released his code with new licenses, so that people could finally start distributing updated versions, rather than the previous approach where lots of people were sharing conflicting patches for various features (e.g. IPv6 support for AAAA…

notqmail.org is for long the defacto maintained version. They had this fixed long time ago.

Re: 15 years later: remote code execution in qmail

#63

Post by rurban »

kbenson wrote: post #59
koheripbal wrote: post #42

Earlier quoted context omitted.

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

Re: 15 years later: remote code execution in qmail

#64

Post by loeg »

will4274 wrote: post #60
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…

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.

As discussed in TFA, he didn't pay out for Georgi Guninski's original discovery in 2005 nor Qualys' rediscovery + working RCE in 2020.

Re: 15 years later: remote code execution in qmail

#65

Post by edoceo »

edoceo wrote: post #18
allover wrote: post #15

Earlier 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'll reply to myself because I cannot edit now.

I meant: my parent comment (@allover) was missing a reference to how ES is insecure by default, this community gives them heck (rightly so) and that this comparison (qmail v. ES) could have been added (ie: was missing) from his post.

For a result of: this is a qmail bug that could/should be fixed AND ES should fix theirs too.

I'm for sure (I thought obviously) not excusing either qmail or ES from being insecure by default or for their "fix" to be: "you're doing it wrong".

I don't think my karma will ever recover from this (Tiger King joke)

Re: 15 years later: remote code execution in qmail

#66

Post by pwdisswordfish2 »

"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, qmail can be protected against all three 2005 CVEs by placing a low, configurable memory limit (a "softlimit") in the startup scripts of all qmail services."

Seems much simpler than patching, let alone trusting someone else's patches.

Interesting that they developed their exploit against Debian's default configuration. qmail from its source at https://cr.yp.to/qmail.html comes with no such default configuration.

Re: 15 years later: remote code execution in qmail

#67

Post by smokecab »

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.

Re: 15 years later: remote code execution in qmail

#68

Post by cadence- »

vinay_ys wrote: post #46
dullgiulio wrote: post #10

Earlier 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...)

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.

Re: 15 years later: remote code execution in qmail

#69

Post by [deleted] »

gowld wrote: post #55
im3w1l wrote: post #12

Earlier quoted context omitted.

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.

[deleted]

Re: 15 years later: remote code execution in qmail

#70

Post by cadence- »

vinay_ys wrote: post #46
dullgiulio wrote: post #10

Earlier 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...)

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.

Here is my favourite that I remember to this day: https://seclists.org/bugtraq/1998/Nov/117
Post reply on HN