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

131–140 of 182 posts

Re: The RCE that AMD won't fix

#131

Post by inetknght »

arghwhat wrote: post #119
Avamander wrote: post #103

This is why I've blocked all HTTP traffic outgoing from my machines. A lot of people have brought this up over the years: https://www.reddit.com/r/AMDHelp/comments/ysqvsv/amd_autoupd... (I'm fairly sure I have even mentioned AMD doing this on HN in the past.) AMD is also not the only one. Gigabyte, ASUS, many other autoupdaters and installers fail without HTTP access. I couldn't even set up my HomePod without allowin…

> Potentially it's even a way for a MITM to exploit the HTTP stack, some content parser or the application's own handling. TLS stacks are a significantly harder target in comparison. For signed payloads there is no difference, you're trusting 's authentication code to read a blob, a signature and validate it according to a public key. For package managers that usually only mean trusting gpg - at the very least no les…

> For signed payloads there is no difference, you're trusting 's authentication code to read a blob, a signature and validate it according to a public key.

Assuming this all came through unencrypted HTTP:

- you're also trusting that the client's HTTP stack is parsing HTTP content correctly

- for that matter, you're also trusting that the server (and any man-in-the-middle) is generating valid HTTP responses

- you're also trusting that the client's response parser doesn't have a vulnerability (and not, say, ignoring some "missing closing bracket" or something)

- you're also trusting that the client is parsing the correct signature (and not, say, some other signature that was tacked-on later)

It's trivially easy to disassemble software to find vulnerabilities like those, though. So it's a lot of trust given for an untrusted software stack.

Re: The RCE that AMD won't fix

#132

Post by [deleted] »

krater23 wrote: post #83

Auto Update is EVERYTIME a RCE. When the software checks a signature, you just need the key. And the delivering enterprise have the key. EVERYTIME. Don't understand why most people mean auto updating software would in any way create more security. It just creates more attack vectors for every software that has a auto updater.

[deleted]

Re: The RCE that AMD won't fix

#133

Post by hhh »

M95D wrote: post #121
Symmetry wrote: post #111

Earlier quoted context omitted.

Years of working in embedded computing have left me with the impression that most hardware companies are just bad at software. I think part of it is that the long cycle times of making hardware push them towards a culture of waterfall development. But years of working with the microcontroller libraries for ethernet PHYs, the bash scripts to build the kernels for SoCs, etc make me perfectly willing to believe they are…

And which are the companies that are good at software? Please, give at least one example.

Apple

Re: The RCE that AMD won't fix

#137

Post by arghwhat »

inetknght wrote: post #131
arghwhat wrote: post #119

Earlier quoted context omitted.

> Potentially it's even a way for a MITM to exploit the HTTP stack, some content parser or the application's own handling. TLS stacks are a significantly harder target in comparison. For signed payloads there is no difference, you're trusting 's authentication code to read a blob, a signature and validate it according to a public key. For package managers that usually only mean trusting gpg - at the very least no les…

> For signed payloads there is no difference, you're trusting 's authentication code to read a blob, a signature and validate it according to a public key. Assuming this all came through unencrypted HTTP: - you're also trusting that the client's HTTP stack is parsing HTTP content correctly - for that matter, you're also trusting that the server (and any man-in-the-middle) is generating valid HTTP responses - you're a…

> 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 special non-TLS variant ("h2c") not being as commonly supported.

> for that matter, you're also trusting that the server (and any man-in-the-middle) is generating valid HTTP responses

You don't, just like you don't trust a TLS server to generate valid TLS (and tunneled HTTP) messages.

> you're also trusting that the client's response parser doesn't have a vulnerability (and not, say, ignoring some "missing closing bracket" or something)

You don't. Authentication 101 (which also applies to how TLS works), authenticity is always validated before inspecting or interacting with content. Same rules that TLS needs to follow when it authenticates its own messages.

Furthermore, TLS does nothing to protect you against a server delivering malicious files (e.g., a rogue maintainer or mirror intentionally giving you borked files).

> you're also trusting that the client is parsing the correct signature (and not, say, some other signature that was tacked-on later)

You don't, as the signature must be authentic from a trusted author (the specific maintainer of the specific package for example). The server or attacker is unable to craft valid signatures, so something "tacked-on" just gets rejected as invalid - just like if you mess with a TLS message.

> It's trivially easy to disassemble software to find vulnerabilities like those, though. So it's a lot of trust given for an untrusted software stack.

The basis of your trust is invalid and misplaced: Not only is TLS not providing additional security here, TLS is the more complex, fragile and historically vulnerable beast.

The only non-privacy risk of using non-TLS mirrors is that a MITM could keep serving you an old version of all your mirrors (which is valid and signed by the maintainers), withholding an update without you knowing. But, such MITM can also just fail your connection to a TLS mirror and then you also can't update, so no: it's just privacy.

Re: The RCE that AMD won't fix

#138

Post by vladvasiliu »

inetknght wrote: post #131
arghwhat wrote: post #119

Earlier quoted context omitted.

> Potentially it's even a way for a MITM to exploit the HTTP stack, some content parser or the application's own handling. TLS stacks are a significantly harder target in comparison. For signed payloads there is no difference, you're trusting 's authentication code to read a blob, a signature and validate it according to a public key. For package managers that usually only mean trusting gpg - at the very least no les…

> For signed payloads there is no difference, you're trusting 's authentication code to read a blob, a signature and validate it according to a public key. Assuming this all came through unencrypted HTTP: - you're also trusting that the client's HTTP stack is parsing HTTP content correctly - for that matter, you're also trusting that the server (and any man-in-the-middle) is generating valid HTTP responses - you're a…

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.

Re: The RCE that AMD won't fix

#140

Post by dns_snek »

arghwhat wrote: post #137
inetknght wrote: post #131

Earlier quoted context omitted.

> For signed payloads there is no difference, you're trusting 's authentication code to read a blob, a signature and validate it according to a public key. Assuming this all came through unencrypted HTTP: - you're also trusting that the client's HTTP stack is parsing HTTP content correctly - for that matter, you're also trusting that the server (and any man-in-the-middle) is generating valid HTTP responses - you're a…

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

Post reply on HN