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

161–170 of 182 posts

Re: The RCE that AMD won't fix

#161

Post by bigfatkitten »

tw04 wrote: post #99
jbstack wrote: post #91

Earlier quoted context omitted.

I don't buy it. It makes sense for a small company where the cost of fixing it might be noticed. But AMD generates some ~$30bn in annual revenues. How much of a developer's time does it take to change the code to use HTTPS? $1000? $5000? Let's be extreme and call it $10,000. That's 0.00003% of AMD's annual revenue. It's barely even a rounding error on their accounts.

You don’t believe it? It took until the early 2000s for Microsoft to take security seriously and they were a money printing machine.

That was a brief chapter in Microsoft’s history. Satya Nadella stopped taking security seriously the day he got in.

Re: The RCE that AMD won't fix

#162

Post by hdgvhicv »

hulitu wrote: post #100
Kodiack wrote: post #74

Earlier quoted context omitted.

Automatic updates are absolutely not peak stupidity. Most users’ devices would have nasty security vulnerabilities wide open for a much longer period of time without automatic updates.

This asuming Automatic updates fix security vulnerabilities, which is almost never the case.

I blindly do apt upgrade all the time. Are you telling me you vet every package?

Re: The RCE that AMD won't fix

#164

Post by mldbk »

Avamander wrote: post #154
arghwhat wrote: post #118

Earlier quoted context omitted.

They usually support both, but important to note that HTTPS is only used for privacy. Package managers generally enforce authenticity through signed indexes and (directly or indirectly) signed packages, although be skeptical when dealing with new/minor package managers as they could have gotten this wrong.

Reducing the benefit of HTTPS to only privacy is dishonest. The difference in attack surface exposed to a MITM is drastic, TLS leaves so little available for any attacker to play with.

MITM usually will not work in case of pkg managers, since packages are signed. But still, attacker can learn what kind of software is installed on target. So I believe that HTTPS for privacy in case of linux package managers are fair enough.

Re: The RCE that AMD won't fix

#166

Post by Avamander »

mldbk wrote: post #164
Avamander wrote: post #154

Earlier quoted context omitted.

Reducing the benefit of HTTPS to only privacy is dishonest. The difference in attack surface exposed to a MITM is drastic, TLS leaves so little available for any attacker to play with.

MITM usually will not work in case of pkg managers, since packages are signed. But still, attacker can learn what kind of software is installed on target. So I believe that HTTPS for privacy in case of linux package managers are fair enough.

The attacker can meddle with every step taken before the signature verification. The way you handle the HTTP responses, the way you handle the signature format, all that. Captive portals have already caused corruption issues for Apt, signed packages be damned.

Saying it's "fair" is like saying engine maintenance does not matter because the tires are inflated. There are more components to it.

Ensuring the correctness of your entire stack against an active MITM is significantly more difficult than ensuring the correctness of just a TLS stack against an active MITM.

Re: The RCE that AMD won't fix

#167

Post by arghwhat »

dns_snek wrote: post #140
arghwhat wrote: post #137

Earlier quoted context omitted.

> you're also trusting that the client's HTTP stack is parsing HTTP content correctly This is an improvement: HTTP/1.1 alone is a trivial protocol, whereas the alternative is trusting the client's much more complicated TLS stack and its HTTP stack. For technical reasons, unencrypted HTTP is also always the simpler (and for bulk transfers more performant) HTTP/1.1 in practice as standard HTTP/2 dictates TLS with the s…

> 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 inspected who owns and operates every single mirror in the mirror list? None of these are trusted by you or by the distro, they're just random third parties - the trust is solely in the package and index signatures of the content they're mirroring.

I'm not suggesting not using HTTPS, but it just objectively wrong to consider it to have reduced your attack surface. At the same time most of its security guarantees are insufficient and useless for this particular task, so in this case the trade-off is solely privacy for complexity.

Re: The RCE that AMD won't fix

#168

Post by arghwhat »

Avamander wrote: post #152
vladvasiliu wrote: post #138

Earlier quoted context omitted.

If you don't trust the http client to not do something stupid, this all applies for https, too. Plus, they can also bork on the ssl verification phase, or skip it altogether.

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

Re: The RCE that AMD won't fix

#169

Post by webstrand »

fulafel wrote: post #160
burnt-resistor wrote: post #57

Earlier quoted context omitted.

That's still a MITM, albeit a LAN-local one. Non-LAN WAN isn't the total scope of MITMs.

If my computer asks your computer what dns server to use, and you respond with the address of a nefarious one, it's not necessarily a mitm.

The MitM happens when the client sends packets to the fake IP, I think the argument goes.

Re: The RCE that AMD won't fix

#170

Post by Tajnymag »

ramon156 wrote: post #151
rtpg wrote: post #3

This is super bad right? Like anybody who has this running will be vulnerable to a super basic HTTP redirect -> installer running on their machine attack, right? And on top of that it's for something that is likely installed on _so many_ machines, right? I don't think I've ever seen something this exploitable that is so prevalent. Like couldn't you just sit in an airport and open up a wifi hotspot and almost immediat…

You can get arrested for this in my country, fun fact. I guess that's how you prevent anything, just make it illegal and the exploit becomes an unintended illegal feature, like occupying the low-freq radio signal.

Just like burglary is illegal in every country on Earth, yet it still happens.
Post reply on HN