[friday99]

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.

[allover]

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?

[icedchai]

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.

[gowld]

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.

[allover]

So it's not secure by default.

[rq1]

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

[tedunangst]

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?

[loeg]

Correct.

[edoceo]

Maybe add a reference to how ElasticSearch (or some other new-pop tech) catches heck for the same?

[allover]

I think you're being downvoted because other things being insecure is not relevant or an excuse.

[edoceo]

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)

[mcguire]

    -m12345678

Ah, magic numbers.