Hacker News Reader

Comment by jl6 | Hacker News Reader

Do we know if they have applied for the $500 bug bounty from DJB?

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 potential 64-bit portability problems allowed a ``remote exploit in qmail-smtpd.'' This claim is denied. Nobody gives gigabytes of memory to each qmail-smtpd process, so there is no problem with qmail's assumption that allocated array lengths fit comfortably into 32 bits.

Under mitigations they list:

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.

Alternatively:

qmail can be protected against the RCE (Remote Code Execution) by configuring the file "control/databytes", which contains the maximum size of a mail message (this file does not exist by default, and qmail is therefore remotely exploitable in its default configuration).

Unfortunately, this does not protect qmail against the LPE (Local Privilege Escalation), because the file "control/databytes" is used exclusively by qmail-smtpd.

Alternatively:

- an updated version of qmail-verify will be available at https://free.acrconsulting.co.uk/email/qmail-verify.html after the Coordinated Release Date;

- the developers of notqmail (https://notqmail.org/) have written their own patches for the three 2005 CVEs and have started to systematically fix all integer overflows and signedness errors in qmail.

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.

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.

So it's not secure by default.

It is in the sense that the author did specify AFAIK the bounds within it should run, no?

Where and when? If I had installed qmail on a 64 bit machine in 2004, how would I have known that it was remotely exploitable?

Correct.

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.

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)

    -m12345678

Ah, magic numbers.

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.

the grown-ups moved to postfix a long time ago

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.

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?

DJB has been telling people to run it with the memory limits since 2005.

Because you care more about the users than about DJB's ego.

Then you should be running Postfix.

When you say "this is squarely a Debian issue", do you mean "in his opinion", or that you agree?

Reply on news.ycombinator.com