
15 years later: Remote Code Execution in qmail (CVE-2005-1513) - jwilk
https://www.openwall.com/lists/oss-security/2020/05/19/8
======
q3k

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

I am more and more convinced that djb does not understand software
engineering.

~~~
gwern
I mentally predicted before clicking through that this would be a remote code
execution vulnerability which affects most or all qmail installations in the
world, and that djb would refuse to pay the bounty, and he would give the
usual blame-the-user excuse along the lines of 'if you had done this separate
thing mentioned in the documentation which I may be the only person to
actually do, the vulnerability would not work'. Imagine my shock when I
clicked through.

------
pengaru
What's surprising to me here is that people are still using qmail in a serious
enough capacity to audit its code.

As a past qmail user of over a decade, that makes me happy.

------
rurban
Just use notqmail. They didn't refuse to fix it, it's actively maintained.
This one was fixed long time ago.

[https://github.com/notqmail/notqmail/pull/37](https://github.com/notqmail/notqmail/pull/37)

~~~
ncmncm
Historical note: It has been traditional to post, in response to reports of
security holes in other mail transports, "Just use qmail."

------
schmonz
We’ve released notqmail 1.08, addressing these vulnerabilities (among other
things). HN discussion thread for the 1.08 release:
[https://news.ycombinator.com/item?id=23252421](https://news.ycombinator.com/item?id=23252421)

------
lightlyused
"we send a very large mail message that contains a very long header line
(nearly 4GB)"

4GB header? Who would let an anonymous person on the internet send you an
email with a 4GB header.

Figure out how to do it with reasonable limits and then I might worry.

~~~
kjs3
Seems like it would be reasonable to say "you know, if a header line gets to,
say, 3.9GB, lets make the reasonable assumption there's something Not Right
and punt it instead of keeping going to overflow".

~~~
lightlyused
Remember the code was written when 32bit OSes were the norm , 4GB of memory
was HUGE, and internet connections were sloooooooow. So a reasonable
assumption at that time was that this will never happen. (Raise your hand if
you've said the same about your own code.) I'm sure there is lots of old code
still running with the same issues, just that the qmail code seems to be
audited a lot. Thankfully it follows a pattern that makes things like this
easy to mitigate.

~~~
kjs3
Yes, having run qmail for most of the 90s, I'm pretty familiar with what was
contemporary. I was being hyperbolic. And yes, there's a lot of code out there
with the same class of flaw.

My point is, the right answer isn't to say "that will never happen" and get
surprised down the road, the right answer is to say "that shouldn't happen"
and do something about it.

So, sure...don't wait till the header gets to 3.9GB. Absurd. But 100MB? 10? 1?
I think I'd get antsy at 1MB. Especially since RFC2822 implies lines can be no
longer than 998 characters. So...you know...someplace between 998B and 1MB
would be reasonable to punt. Especially at the time the code was written.

