15 years later: Remote Code Execution in qmail (CVE-2005-1513) | Hacker News Reader

15 years later: Remote Code Execution in qmail (CVE-2005-1513)

openwall.com

20 pointsjwilk11 comments

    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.

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.

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.

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

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

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

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

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

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.

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.

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

You mean, do it within the 'reasonable limits' which aren't there in the default package or in any versions such as provided by eg Debian...?

Reply on news.ycombinator.com