Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

15 years later: remote code execution in qmail

qualys.com

Post reply on HN
Print view View original

131–140 of 164 posts

Re: 15 years later: remote code execution in qmail

#131

Post by ptx »

dependenttypes wrote: post #126
antirez wrote: post #51

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.

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.

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.

Re: 15 years later: remote code execution in qmail

#133

Post by erik_seaberg »

dependenttypes wrote: post #122
titzer wrote: post #111

Earlier quoted context omitted.

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.

It is about safe and unsafe implementations rather than safe and unsafe languages.

Can we name any programmers who are actually capable of a safe implementation using an unsafe language? DJB failed, Knuth's code has bugs, how can I expect you or I to succeed?

Re: 15 years later: remote code execution in qmail

#134

Post by xorcist »

peterwwillis wrote: post #113
mmm_grayons wrote: post #30

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.

Postfix has much more functionality out of the box so the comparison isn't really fair.

Both are examples of extremely well designed software written with care by security minded persons.

Re: 15 years later: remote code execution in qmail

#135

Post by dependenttypes »

erik_seaberg wrote: post #133
dependenttypes wrote: post #122

Earlier quoted context omitted.

It is about safe and unsafe implementations rather than safe and unsafe languages.

Can we name any programmers who are actually capable of a safe implementation using an unsafe language? DJB failed, Knuth's code has bugs, how can I expect you or I to succeed?

I am not talking about safe implementations of programs but rather safe implementations of languages. A (kind of bad example because it does not catch everything) is the address sanitiser that clang and gcc have.

Re: 15 years later: remote code execution in qmail

#136

Post by dependenttypes »

titzer wrote: post #130
dependenttypes wrote: post #122

Earlier quoted context omitted.

It is about safe and unsafe implementations rather than safe and unsafe languages.

This specific type of vulnerability and the tens of thousands of similar ones like it would absolutely have been prevented by a safe programming language.

This specific type of vulnerability would not be an issue in a safe C implementation for example, just like it would be an issue in an unsafe rust implementation.

Re: 15 years later: remote code execution in qmail

#137

Post by mjg59 »

dependenttypes wrote: post #120
sneak wrote: post #101

Earlier quoted context omitted.

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 wit…

My opinions around DJB have very little to do with my political beliefs, but rather more to do with spending time with people who are far better at cryptography than he is without having anything approaching his ego.

Re: 15 years later: remote code execution in qmail

#138

Post by dependenttypes »

jedberg wrote: post #129
dependenttypes wrote: post #128

Earlier quoted context omitted.

> and refuses to admit I wish people stopped repeating it over and over. See https://news.ycombinator.com/item?id=23250748

So he paid a bonus one time? And that negates all the other times he refused to admit he was wrong (including the time this very article is about, twice)?

> So he paid a bonus one time?

Yes, which invalidates your statement that said "refuses to admit when he makes a mistake".

> And that negates all the other times he refused to admit he was wrong

No, I personally think that he should have awarded the 2005 report.

Considering that we have one example where he rewarded the bountry and one where he did not I would say that "he has such a big ego and refuses to admit when he makes a mistake" is just as valid as "he is humble and admits it when he makes a mistake"

Re: 15 years later: remote code execution in qmail

#139

Post by morelisp »

dependenttypes wrote: post #116
kelnos wrote: post #94

Earlier quoted context omitted.

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.

Putting aside question of if can have responsibility for freely-released work (especially when one has made a big deal of money offered in exchange for this kind of finding), at the time this bug was discovered the software was emphatically not in the public domain and difficult to distribute modified versions of despite available source.

Re: 15 years later: remote code execution in qmail

#140

Post by loup-vaillant »

pwdisswordfish2 wrote: post #97
loup-vaillant wrote: post #92

Earlier quoted context omitted.

I could trust softlimit all right, but my point was that I wouldn't trust users to wield it correctly.

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.

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.
Post reply on HN