
15 years later: remote code execution in qmail - fanf2
https://www.qualys.com/2020/05/19/cve-2005-1513/remote-code-execution-qmail.txt
======
pfortuny
Oh, dear. Another "will never happen" issue which, after not so long (in the
history of mankind) takes place. And this one would not have been so
complicated to fix (just enforce a limit as the author suggests).

    
    
        /* this line is unreachable */
        printf("You have reached unreachable code\n");
    

10 years later, it gets printed...

~~~
bluejekyll
Why not exit/panic at that point? Seems like the right thing for any
“unreachable” code.

~~~
asveikau
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 the process when not necessary,
turning it into a DoS.

Edit: I am not sure if my friend the downvoter realizes I am not trying to
justify legit security bugs, just talking abstractly about varying approaches
to handling asserts for unforeseen or "allegedly impossible" circumstances.

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

~~~
chasil
Solaris also notably bundles 32-bit binaries for most everything in /bin with
64-bit distributions, and that begins to look like a wise choice.

I recently observed that SmartOS does the same.

------
antirez
That's quite interesting because the bug was there and was quite clear, and
was not fixed by one of the most brilliant security persons out there (DJB).
Maybe here the attitude really was the wrong one, considering how security
oriented qmail was since the start, because the simplest possible fix does not
seem to demand any other dimension, like complexity or performances.

~~~
dependenttypes
While I think that he should have rewarded the original 2005 bug report I do
not think that he did anything wrong after that. He was pretty clear about the
memory limit for years now.

~~~
ptx
If the program only runs correctly with a memory limit in place, perhaps it
should (if this is possible?) check for a memory limit when it starts and
abort if it's missing.

------
DominoTree
Serious question: Was there a legitimate reason they didn't patch this stuff
when it was first discovered?

~~~
dullgiulio
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...)

~~~
koheripbal
I don't understand. Most people with a big ego would not want a critical
vulnerability associated with them. Can you elaborate?

~~~
kbenson
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 for him to swallow.

1:
[https://cr.yp.to/qmail/guarantee.html](https://cr.yp.to/qmail/guarantee.html)

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

~~~
Chlorus
> One should not use so much memory for a mail server, way too risky.

Is there a table or formula I can consult that will give this particular dumb
person(myself) a handy guide for what amounts of addressable memory will
introduce security risks for particular applications? Apparently more than
32-bits is obviously[0] a problem for email; what about databases? Should I
feel bad I use more than 64GB of memory in my DB installations? Am I being
irresponsible? What about web servers? How much risk does each additional bit
of memory add?

My final question is, why does pretty much every other software maintainer not
have a problem fixing the memory allocation themselves, obviating the need for
external tools to fix these issues? I guess they're going the extra mile!

[0] So obvious a problem that sendmail, postfix, and exim don't require me to
apply workarounds for it for some reason. Very irresponsible of them, if you
ask me.

------
jkuperus
This is great. I remember when this came out. Georgi Guninski was a very
accomplished bug hunter. Well known for finding vulnerabilities in web browers
(ie. internet explorer) But the security community frowned upon that a bit as
"not real hacking" so he was like "hold my beer", went after the hardest
"real" target you could find and this was the result.

The guy is a legend

------
upofadown
The surprising thing here for me was that you can send qmail a 4GB email
message and it will not immediately reject it in the default configuration.

~~~
gowld
4GB was impossible when qmail was last updated.

~~~
wahern
According to Wikipedia DJB's last release was 1998. 64-bit Alpha and SPARC V9
were in widespread use by then. Even Linux was ported to Alpha in 1995.[1] See
[https://www.linuxjournal.com/article/1044](https://www.linuxjournal.com/article/1044)

[1] Actually, Jim Paradis announced the Linux/Alpha development kit January
23, 1995 on comp.os.linux.announce (Message-ID:
3g0787$59i@kruuna.Helsinki.FI). So it's possible he had the kernel ported in
late 1994. He announced a fully functional distribution July 1, 1995.
(Message-ID: 3t34ph$mi@kruuna.helsinki.fi)

------
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](https://cr.yp.to/qmail.html) comes with no such
default configuration.

~~~
loup-vaillant
> _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 heavily scrutinised) small third
party patch?

~~~
pwdisswordfish2
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](https://cr.yp.to/daemontools/softlimit.html)

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

~~~
loup-vaillant
I could trust softlimit all right, but my point was that I wouldn't trust
_users_ to wield it correctly.

~~~
pwdisswordfish2
softlimit is not difficult to use, certainly no more difficult than patch.
programs like tinydns-conf for example autmatically generate a run script
containing softlimit with a recommended -m setting. maybe qmail needs
something similar.

~~~
loup-vaillant
I was talking about patching _upstream_ , okay? It's not like the patch would
have to be individually applied to each installation by its own admin. Patch
upstream once, and poof, all users worldwide are safe as soon as they update.

~~~
pwdisswordfish2
Perhaps "Seems much simpler than patching" was an ambiguous statement. I was
only referring to the perspective I take as an admin for one user: me. I
already use softlimit on a daily basis so it is simpler for me than patching.
To me, it seems like a cleaner solution. The two _complete_ mitigations
presented were a choice between (a) using softlimit and the -m setting used by
qmail's author versus (b) applying a third party patch to fix problems caused
by another third party patch (qmail-verify, which was an "upadte" of yet
another third party patch) and third party configuration settings (Debian). I
thought that was noteworthy.

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

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

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

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

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

~~~
loup-vaillant
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](https://cr.yp.to/qmail.html) means DJB is
(possibly unintentionally) still vouching for it. Right now in 2020.

------
myrond
Maybe this will be useful to someone adding the following flags LDFLAGS='-z
relro -z now' help with one of the holes (they mentioned it, but not what
flags) Check out:
[https://github.com/slimm609/checksec.sh](https://github.com/slimm609/checksec.sh)

    
    
      * System-wide ASLR (kernel.randomize_va_space): Full (Setting: 2)
      * Does the CPU support NX: Yes
      * Core-Dumps access to all users: Restricted
               COMMAND         PID RELRO      STACK CANARY            SECCOMP          NX/PaX        PIE                     FORTIFY
      # checksec --proc-all |grep qmail
          qmail-injectXXXXX27 Full RELRO      Canary found            Seccomp-bpf      NX enabled    PIE enabled             Yes
           qmail-queueXXXXX97 Full RELRO      Canary found            Seccomp-bpf      NX enabled    PIE enabled             Yes
            qmail-sendXXXXX78 Full RELRO      Canary found            Seccomp-bpf      NX enabled    PIE enabled             Yes
          qmail-lspawnXXXXX89 Full RELRO      Canary found            Seccomp-bpf      NX enabled    PIE enabled             Yes
          qmail-rspawnXXXXX90 Full RELRO      Canary found            Seccomp-bpf      NX enabled    PIE enabled             Yes
           qmail-cleanXXXXX91 Full RELRO      Canary found            Seccomp-bpf      NX enabled    PIE enabled             Yes

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

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

~~~
ergothus
I'm not a psychologist so I should probably shut up, but I'll continue:

It seems like it does hit the tech field more often, yet overwhelmingly I see
leading people in tech get softer, more empathetic, and more open to outside
ideas the longer they work and the more experience they gain.

Perhaps this is selection bias (the people I see are the "popular" ones, so of
course they are the ones with more social awareness), or perhaps there is no
hard and fast "genius requires ego". Note: I'm aware you didn't say that it
did, you only mentioned that abrasive-ness seems disproportionately frequent
in the tech field.

I'm all for improving our understanding and ways of communication - I've
definitely known people in the "asshole" category that were surprised and
bothered to discover that was how they came across - but I'm not interested in
normalizing abuse as a necessary cost. Which, again, you didn't say nor imply,
but the concepts are related to what you've brought up, so I mention it here
because the topic is interesting, not as a counterpoint.

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

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

~~~
Snelius
"But we need to rewrite it with Rust!!" Crazy..

~~~
mmm_grayons
I said nothing about rust, and the alternative I proposed (postfix) is written
in C.

------
mftest
Does anybody still use qmail in Production. I see on DJB's website that it is
used in 700K sites but I doubt that assumption. Also the code has not been
updated in almost a decade. How or why do sysadmins decide to go with qmail in
2020

~~~
ansible
You can use a heap of patches for qmail, but I wouldn't recommend it.

I was using Courier MTA for a while for self-hosting email.

I may do so again, and will likely use mailcow or mail in a box. Neither are
based on qmail.

------
foota
I would bet a lot of upvotes on this come from people misreading this as Gmail
as I did :)

~~~
gerdesj
No. I ran several Qmails for many years on Mandrake with daemontools to
supervise. All compiled from source. Lovely. "Life with Qmail" is a classic.

I needed some additional flexibility and switched to Exim for my MTA of choice
instead but have fond memories of Qmail.

------
xvilka
One thing that might help to improve overall qmail code quality (even though
it's already written by a genius of our time) is to rewrite qmail in Rust[1].

[1]
[https://github.com/notqmail/notqmail/issues/115](https://github.com/notqmail/notqmail/issues/115)

~~~
peterwwillis
The only way that could improve the quality is for _DJB_ to rewrite it in
Rust. If anyone else rewrote it in Rust, it would just contain different
security bugs, and probably run worse.

~~~
knbt
The code is concise k&r c, converting it to any language could be an
informative experience

