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

The RCE that AMD won't fix

mrbruh.com

Post reply on HN
Print view View original

171–180 of 182 posts

Re: The RCE that AMD won't fix

#171

Post by Avamander »

arghwhat wrote: post #167
dns_snek wrote: post #140

Earlier quoted context omitted.

> HTTP/1.1 alone is a trivial protocol Eh? CWE-444 would beg to differ: https://cwe.mitre.org/data/definitions/444.html https://http1mustdie.com/ > the alternative is trusting the client's much more complicated TLS stack and its HTTP stack. An attacker doesn't get to attack client's HTTP stack without first piercing protection offered by TLS.

You seem to have forgotten all the critical TLS bugs we had. Heartbleed ring a bell? > An attacker doesn't get to attack client's HTTP stack without first piercing protection offered by TLS. You misunderstand: this means more attack surface. The attacker can mess with the far more complex and fragile TLS stack, and any attacker controlling a server or server payload can also attack the HTTP stack. Have you recently i…

That was a long time ago and it was specific to one implementation. In comparison GnuPG has had so many critical vulnerabilities even recently. That's why Apt switched to Sequoia.

Modern TLS stacks are far from fragile, especially in comparison to PGP implementations. It's a significant reduction in attack surface when it's a MITM we're talking about.

Malicious mirrors remain a problem, but having TLS in the mix doesn't make it more dangerous. Potential issues with PGP, HTTP and Apt's own logic are just so much more likely.

Re: The RCE that AMD won't fix

#172

Post by Avamander »

arghwhat wrote: post #168
Avamander wrote: post #152

Earlier quoted context omitted.

TLS stacks are generally significantly harder targets than HTTP ones. It's absolutely possible to use one incorrectly, but then we should also count all the ways you can misuse a HTTP, there are a lot more of those.

This statement makes no sense, TLS is a complicated protocol with implementations having had massive fun and quite public security issues, while HTTPS means you have both and need to deal with a TLS server feeing you malicious HTTP responses. Having to harden two protocol implementations, vs. hardening just one of those. (Having set up letsencrypt to get a valid certificate does not mean that the server is not malici…

TLS may be complicated for some people. But unlike HTTP, it has even formally proven correct implementations. You can't say the same about HTTP, PGP and Apt.

> Having to harden two protocol implementations, vs. hardening just one of those.

We're speaking of a MITM here. In that case no, you don't have to harden both. (Even if you did have to, ain't nobody taking on OpenSSL before all the rest, it's not worth the effort.)

I find it kind-of weird that you can't understand that if all a MITM can tamper with is the TLS then it's irrefutably a significantly smaller surface than HTTP+PGP+Apt.

Re: The RCE that AMD won't fix

#173

Post by carefree-bob »

Delk wrote: post #142
tgsovlerkhgsel wrote: post #129

Earlier quoted context omitted.

"Thank you for hacking our product" sounds perfectly appropriate to me; it clearly uses "hacking" in the positive sense.

It actually says "hacking on one of our programs", which makes it even more obvious that it's using the word closer to the positive traditional hacker culture sense. I'm sure that still looks unprofessional to some people, just like any jargon that isn't corporatese does.

I could have been giving this an uncharitable reading.

Re: The RCE that AMD won't fix

#175

Post by arghwhat »

Avamander wrote: post #171
arghwhat wrote: post #167

Earlier quoted context omitted.

You seem to have forgotten all the critical TLS bugs we had. Heartbleed ring a bell? > An attacker doesn't get to attack client's HTTP stack without first piercing protection offered by TLS. You misunderstand: this means more attack surface. The attacker can mess with the far more complex and fragile TLS stack, and any attacker controlling a server or server payload can also attack the HTTP stack. Have you recently i…

That was a long time ago and it was specific to one implementation. In comparison GnuPG has had so many critical vulnerabilities even recently. That's why Apt switched to Sequoia. Modern TLS stacks are far from fragile, especially in comparison to PGP implementations. It's a significant reduction in attack surface when it's a MITM we're talking about. Malicious mirrors remain a problem, but having TLS in the mix does…

If you believe TLS is more fragile than PGP and plain HTTP, then I have reason to believe you have never looked at any of those wire protocols/file formats and the logic required.

Adding TLS in front of HTTP when talking to an untrusted third-party server (and yes, any standard HTTPS server is untrusted int his context), can only ever increase your attack surface. The only scenario where it reduces the attack surface is if you are connected with certificate pinning to a trusted server implementation serving only trusted payloads, and neither is the case for a package repo - that's why we have file signatures in the first place.

Re: The RCE that AMD won't fix

#176

Post by arghwhat »

Avamander wrote: post #172
arghwhat wrote: post #168

Earlier quoted context omitted.

This statement makes no sense, TLS is a complicated protocol with implementations having had massive fun and quite public security issues, while HTTPS means you have both and need to deal with a TLS server feeing you malicious HTTP responses. Having to harden two protocol implementations, vs. hardening just one of those. (Having set up letsencrypt to get a valid certificate does not mean that the server is not malici…

TLS may be complicated for some people. But unlike HTTP, it has even formally proven correct implementations. You can't say the same about HTTP, PGP and Apt. > Having to harden two protocol implementations, vs. hardening just one of those. We're speaking of a MITM here. In that case no, you don't have to harden both. (Even if you did have to, ain't nobody taking on OpenSSL before all the rest, it's not worth the effo…

> We're speaking of a MITM here

We are speaking of the total attack surface.

1. When it comes to injecting invalid packets to break a parser, you can MITM TLS without problem. This is identical to the types of attack you claimed were relevant to HTTP-only, feeding invalid data that would be rejected by authentication of the signature.

2. Any server owning a domain name can have a valid TLS certificate, creating "trusted" connections, no MITM necessary. Any server in your existing mirrorlist can go rogue, any website you randomly visit might be evil. They can send you both signed but evil TLS packets, and malicious HTTP payloads.

3. Even if the server is good, it's feeding you externally obtained data that too could be evil.

There is no threat model here where you do not rely 100% on the validity of the HTTP stack and file signature checking. TLS only adds another attack surface, by running more exploitable code on your machine, without taking away any vulnerabilities in what it protects.

Re: The RCE that AMD won't fix

#177

Post by Avamander »

arghwhat wrote: post #175
Avamander wrote: post #171

Earlier quoted context omitted.

That was a long time ago and it was specific to one implementation. In comparison GnuPG has had so many critical vulnerabilities even recently. That's why Apt switched to Sequoia. Modern TLS stacks are far from fragile, especially in comparison to PGP implementations. It's a significant reduction in attack surface when it's a MITM we're talking about. Malicious mirrors remain a problem, but having TLS in the mix does…

If you believe TLS is more fragile than PGP and plain HTTP, then I have reason to believe you have never looked at any of those wire protocols/file formats and the logic required. Adding TLS in front of HTTP when talking to an untrusted third-party server (and yes, any standard HTTPS server is untrusted int his context), can only ever increase your attack surface. The only scenario where it reduces the attack surface…

I have implemented parts of all three. I doubt you have.

> Adding TLS in front of HTTP when talking to an untrusted third-party server, can only ever increase your attack surface.

No, against a MITM it instantly subtracts the surface inside the TLS from the equation. Which is the entire point.

> [...] that's why we have file signatures in the first place.

You still don't understand that even before the cryptographic operations done in order to verify the signatures you have all those other layers. Layers that are complex to implement, easy to misinterpret and repeatedly to this day found flawed. PGP is so terrible no serious cryptographer even bothers looking at it this day and age.

I start getting the feeling that you're involved in keeping the package repositories stuck in the past. I can't wait for yet another Apt bug where some MITM causes problems yet again.

Re: The RCE that AMD won't fix

#178

Post by Avamander »

arghwhat wrote: post #176
Avamander wrote: post #172

Earlier quoted context omitted.

TLS may be complicated for some people. But unlike HTTP, it has even formally proven correct implementations. You can't say the same about HTTP, PGP and Apt. > Having to harden two protocol implementations, vs. hardening just one of those. We're speaking of a MITM here. In that case no, you don't have to harden both. (Even if you did have to, ain't nobody taking on OpenSSL before all the rest, it's not worth the effo…

> We're speaking of a MITM here We are speaking of the total attack surface. 1. When it comes to injecting invalid packets to break a parser, you can MITM TLS without problem. This is identical to the types of attack you claimed were relevant to HTTP-only, feeding invalid data that would be rejected by authentication of the signature. 2. Any server owning a domain name can have a valid TLS certificate, creating "trus…

No, you want to move goalposts, but we're not speaking of some arbitrary "total attack surface". The article itself is also about a potential MITM. Then you list three cherry-picked cases, none of which actually touch upon the concerns that a plaintext connection introduces or exposes. Please stop, it's silly.

There is fundamentally no reasonable threat model where a plaintext connection (involving all these previously listed protocols) is safer against a MITM than an encrypted and authenticated one.

Re: The RCE that AMD won't fix

#179

Post by arghwhat »

Avamander wrote: post #178
arghwhat wrote: post #176

Earlier quoted context omitted.

> We're speaking of a MITM here We are speaking of the total attack surface. 1. When it comes to injecting invalid packets to break a parser, you can MITM TLS without problem. This is identical to the types of attack you claimed were relevant to HTTP-only, feeding invalid data that would be rejected by authentication of the signature. 2. Any server owning a domain name can have a valid TLS certificate, creating "trus…

No, you want to move goalposts, but we're not speaking of some arbitrary "total attack surface". The article itself is also about a potential MITM. Then you list three cherry-picked cases, none of which actually touch upon the concerns that a plaintext connection introduces or exposes. Please stop, it's silly. There is fundamentally no reasonable threat model where a plaintext connection (involving all these previous…

You don't call it "cherry-picking" when a person lists fundamental flaws in your argument.

Constantly ignoring all the flaws outlined and just reiterating your initial opinion with no basis whatsoever is at best ignorance, at worst trolling.

HTTP with signed packages is by definition a protocol with authenticated payloads, and encryption exclusively provides privacy. And no, we're not singeling out the least likely attack vector for the convenience of your argument - we're looking at the whole stack.

Re: The RCE that AMD won't fix

#180

Post by arghwhat »

Avamander wrote: post #177
arghwhat wrote: post #175

Earlier quoted context omitted.

If you believe TLS is more fragile than PGP and plain HTTP, then I have reason to believe you have never looked at any of those wire protocols/file formats and the logic required. Adding TLS in front of HTTP when talking to an untrusted third-party server (and yes, any standard HTTPS server is untrusted int his context), can only ever increase your attack surface. The only scenario where it reduces the attack surface…

I have implemented parts of all three. I doubt you have. > Adding TLS in front of HTTP when talking to an untrusted third-party server, can only ever increase your attack surface. No, against a MITM it instantly subtracts the surface inside the TLS from the equation. Which is the entire point. > [...] that's why we have file signatures in the first place. You still don't understand that even before the cryptographic…

> I start getting the feeling that you're involved in keeping the package repositories stuck in the past.

I start getting the feeling that you have no actual experience in threat modelling.

Post reply on HN