Serious question: Was there a legitimate reason they didn't patch this stuff when it was first discovered?
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...)
15 years later: remote code execution in qmail
101–110 of 164 posts
Re: 15 years later: remote code execution in qmail
#102The 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.
4GB was impossible when qmail was last updated.
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
[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)
Re: 15 years later: remote code execution in qmail
#103Earlier quoted context omitted.
Yeah, that footgun should really have a more explicit name. __dear_compiler_i_promise_that_this_statement_is_unreachable_and_you_may_optimize_based_on_my_good_word_upon_penalty_of_undefined_behaviour()
Even better, just actually perform undefined behavior on that branch and the compiler will get rid of it.
This is literally what __builtin_unreachable() does. But it has the added benefit of the compiler understanding the intent so it works well with diagnostics.
Re: 15 years later: remote code execution in qmail
#104Earlier quoted context omitted.
http://cr.yp.to/talks/2007.11.02/slides.pdf I don't see ego in these slides. I see a brilliant programmer acknowledging his mistakes and learning from them. I really enjoyed running qmail in early 2000s and following djb's crypto work later. He is brilliant indeed.
Here is my favourite that I remember to this day: https://seclists.org/bugtraq/1998/Nov/117
Hah, "How many people relaxed after installing tcpd -DPARANOID, instead of pestering their vendors for a real fix?" Sounds similar here ;)
Re: 15 years later: remote code execution in qmail
#105This 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.
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.
"But we need to rewrite it with Rust!!"
Crazy..
Re: 15 years later: remote code execution in qmail
#106One 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].
Re: 15 years later: remote code execution in qmail
#107Oh, 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...
You have reached an imaginary program state. Please rotate your computer by 90 degrees and try again. (paraphrased from a friend's answering-machine message)
I did that, but it's still a bit complex for me…
Re: 15 years later: remote code execution in qmail
#108Earlier quoted context omitted.
Even better, just actually perform undefined behavior on that branch and the compiler will get rid of it.
This is literally what __builtin_unreachable() does. But it has the added benefit of the compiler understanding the intent so it works well with diagnostics.
But that's a builtin, rather than something that's part of the core language :)
Re: 15 years later: remote code execution in qmail
#109Earlier quoted context omitted.
Yeah, that footgun should really have a more explicit name. __dear_compiler_i_promise_that_this_statement_is_unreachable_and_you_may_optimize_based_on_my_good_word_upon_penalty_of_undefined_behaviour()
I mean, what other semantics would anyone expect it to have—presuming they think for a moment about why it exists as its own thing in the first place?
Rust being Rust, the equivalent causes a safe teardown.
https://doc.rust-lang.org/std/macro.unreachable.html
The UB causing equivalent is of course unsafe.
https://doc.rust-lang.org/std/hint/fn.unreachable_unchecked....
Re: 15 years later: remote code execution in qmail
#110Earlier quoted context omitted.
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 f…
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.
> 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.