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

141–150 of 164 posts

Re: 15 years later: remote code execution in qmail

#141

Post by morelisp »

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…

> even nacl suggest against it

You're defending djb's decision by pointing to another of his projects, which in turn cites another email from djb. I'm not saying you're wrong¸ but it's not exactly a reviewed position.

Re: 15 years later: remote code execution in qmail

#142

Post by loup-vaillant »

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.

When you release software for the world to use, tell everyone it's secure, even put up a bug bounty… that kinda means you are taking responsibility.

Re: 15 years later: remote code execution in qmail

#143

Post by morelisp »

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…

> a bone to pick with DJB due to their personal political beliefs

"Political beliefs" is a weird way to say DJB has stepped up to defend at least three people accused of sexual abuse by multiple victims.

Re: 15 years later: remote code execution in qmail

#144

Post by dependenttypes »

morelisp wrote: post #141
dependenttypes wrote: post #120

Earlier quoted context omitted.

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…

> even nacl suggest against it You're defending djb's decision by pointing to another of his projects, which in turn cites another email from djb. I'm not saying you're wrong¸ but it's not exactly a reviewed position.

I meant it in another way. If he had taken DJB's advice this would not be an issue, so DJB can't be blamed for it. Sorry for the misunderstanding.

That being said, he seems to agree with this. After all he followed said advice in his tool age.

Re: 15 years later: remote code execution in qmail

#145

Post by dependenttypes »

morelisp wrote: post #143
dependenttypes wrote: post #120

Earlier quoted context omitted.

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…

> a bone to pick with DJB due to their personal political beliefs "Political beliefs" is a weird way to say DJB has stepped up to defend at least three people accused of sexual abuse by multiple victims.

I actually had https://blog.cr.yp.to/20160607-dueprocess.html in mind when mentioning political beliefs, but even then I think that this still falls under the "political belief" label - the belief that anyone accused of rape should not have any form of defence. Anyway, the person who is being sued was part of a harassment campaign against multiple people, including Bernstein himself, so I can't see why it would be a bad thing for him to send his declaration.

For anyone interested, his declaration is here: https://www.courtlistener.com/recap/gov.uscourts.cand.340308...

And here is the most objective and complete story of the Appelbaum events that I have personally seen so far https://github.com/Enegnei/JacobAppelbaumLeavesTor/blob/mast... (if anyone has anything better please do let me know)

> accused of sexual abuse by multiple victims

Including false accusations by others in the name of the so called victims. Such as the "Alice" case. (if I am not mistaken this specific accusation was published by the person being sued themselves)

Re: 15 years later: remote code execution in qmail

#146

Post by dullgiulio »

dependenttypes wrote: post #127
sneak wrote: post #124

Earlier quoted context omitted.

Your criticism of the messenger of further evidence of djb's longstanding refusal to deal straightforwardly with security reports is not on topic, IMO. Not everything is a simple dichotomy.

(regarding qmail) It was a security bug back in 2005. It stopped being a security bug when DJB mentioned on the official page about the memory limits. Regarding the salsa20 implementation: I just mentioned in my previous message why this was not a bug and the only reason that people were upset over it was due to Filo's incompetence. As for evidence of DJB dealing straightforwardly with security reports: https://news.…

salsa20 was added in 2012, the warning file was added into the repository in 2016 the earliest (it is not clear when--which is vary bad for security and also shows the move was not advertised.)

Incompetence is a strong word on the wrong target...

Re: 15 years later: remote code execution in qmail

#147

Post by dependenttypes »

dullgiulio wrote: post #146
dependenttypes wrote: post #127

Earlier quoted context omitted.

(regarding qmail) It was a security bug back in 2005. It stopped being a security bug when DJB mentioned on the official page about the memory limits. Regarding the salsa20 implementation: I just mentioned in my previous message why this was not a bug and the only reason that people were upset over it was due to Filo's incompetence. As for evidence of DJB dealing straightforwardly with security reports: https://news.…

salsa20 was added in 2012, the warning file was added into the repository in 2016 the earliest (it is not clear when--which is vary bad for security and also shows the move was not advertised.) Incompetence is a strong word on the wrong target...

> the warning file was added into the repository in 2016 the earliest

There is no official public repository. It gets released in tarballs.

This does indeed make him seem slightly less incompetent though.

> which is vary bad for security

It is a framework for benchmarking cryptographic algorithms.

Re: 15 years later: remote code execution in qmail

#148

Post by Dylan16807 »

dependenttypes wrote: post #136
titzer wrote: post #130

Earlier quoted context omitted.

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.

"safe C" and "unsafe Rust" sound like variant languages to me.

Re: 15 years later: remote code execution in qmail

#149

Post by dependenttypes »

Dylan16807 wrote: post #148
dependenttypes wrote: post #136

Earlier quoted context omitted.

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.

"safe C" and "unsafe Rust" sound like variant languages to me.

How is "safe C" a variant language when it is within what the standard allows?

Re: 15 years later: remote code execution in qmail

#150

Post by Quekid5 »

Snelius wrote: post #104
cadence- wrote: post #70

Earlier quoted context omitted.

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

Yeah, the lack of self-reflection is pretty palpable.
Post reply on HN