Live data from Hacker News

15 years later: remote code execution in qmail

qualys.com

111–120 of 164 posts

Re: 15 years later: remote code execution in qmail

#111

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.

Integer overflow bug causing manual memory allocation bug leading to RCE. All too common. We need to stop relying on software written in unsafe languages.

Re: 15 years later: remote code execution in qmail

#112
post #106

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

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.

Re: 15 years later: remote code execution in qmail

#113

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.

Postfix has 9 CVEs. Qmail has 1. It would seem the numbers don't agree with you.

Re: 15 years later: remote code execution in qmail

#114
post #24

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.

> I really hate supporting that.

It appears the only victim of your spite is yourself. (Hmmm... there's an old saying along these lines.)

Re: 15 years later: remote code execution in qmail

#115

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

[deleted]

Re: 15 years later: remote code execution in qmail

#116
post #94

Earlier quoted context omitted.

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

The funny thing about that is I find his code to be very difficult to read (even just the snippets in the linked CVE illustrate this). And his attitude is just bonkers to me. "I'm not going to fix this exploitable security issue because I assume that people will configure their environment in a particular way." What? That's... flat-out irresponsible.

He does not have any responsibility against anyone. He released his software in public domain with the source included for free.

Re: 15 years later: remote code execution in qmail

#117
post #106

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

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.

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

Re: 15 years later: remote code execution in qmail

#118
post #59

Earlier quoted context omitted.

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

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…

He did reward some other bounties that he made, I can only think the ones from his cryptographic algorithms at the moment though.

Edit: See https://news.ycombinator.com/item?id=23250748

Re: 15 years later: remote code execution in qmail

#119
post #91
post #61

Earlier quoted context omitted.

So it's not secure by default.

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

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?

Re: 15 years later: remote code execution in qmail

#120
post #101

Earlier quoted context omitted.

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

https://twitter.com/FiloSottile/status/1262854396934791168

Filo is upset that he did not bother to check the code (that originally came from SUPERCOP, a benchmarking tool) he blindly included in go's xcrypto. Here is DJB's tweet: https://twitter.com/hashbreaker/status/1108637226089496577

(regardless, you should not directly encrypt a large amount of data, even nacl suggest against it https://nacl.cr.yp.to/valid.html)

In addition both Filo and Garrett have a bone to pick with DJB due to their personal political beliefs and his involvement in the Appelbaum case and I found both of them to be extremely dislikeable and unable to accept their own faults in personal discussions that I had with them in the past (regarding different issues). Considering that this was a subpost my opinion of them is even lower now.

Post reply on HN