Live data from Hacker News

The RCE that AMD wouldn't fix

mrbruh.com

31–40 of 131 posts

Re: The RCE that AMD wouldn't fix

#31

The "signature verification" in the fix being CRC32 is pretty hilariously clueless.

It's technically possible (though I don't know if they actually do this) that they're not referring to a signature check in the download part, but are verifying the code signing signature of the executable downloaded. You'd only notice the CRC if you were looking at the downloaded content, but if the updater refuses to launch an executable that isn't signed by AMD's cert then they would be fine.

Given the way AMD has been treating this issue, I'm assuming they're just incompetent, though.

Re: The RCE that AMD wouldn't fix

#32
post #10

Earlier quoted context omitted.

That's in fact often not their core purpose !

What is it?

(First, I'm sorry I was so terse upthread; I had to get up early for a meeting and was scrolling HN in bed while it was happening without my reading glasses on; I should learn to stop commenting when I'm like that.)

I've written about this before here, but to sum it up:

* Unless something wild happens in software engineering (formal methods, &c) as a result of AI, there's no such thing as eradicating security vulnerabilities. Focused programs can eliminate low-hanging fruit, but at the point where you're offering significant bounties part of the premise is that all that fruit has been plucked. The marginal security impact of a single bounty award, by itself, is immaterial.

* What bounty programs can do is focus internal engineering attention. Large product teams have huge backlogs of issues and security design punch lists. For features and feature bugs, there's a closed loop that prioritizes the work: the market. For security vulnerabilities, bounties serve a similar purpose. This is why many bounties are tightly scoped; the whole point of the program is to direct the efforts of specific product teams.

* When we're talking about 10,000+ person engineering teams, the most important thing to know about bug bounty programs is that the company is incentivized to pay out. No major tech company that runs a bounty is "covering up" vulnerabilities. There's no reason for them to do so. They're running a program that ostentatiously pays rewards to people who report vulnerabilities! There are people on the teams managing the bounties who in effect get paid more when the program pays out more: that's what success looks like.

You add all this stuff up and all the drama about AMD (or Google or whoever) being shady or stingy basically never add up.

Re: The RCE that AMD wouldn't fix

#33
post #10

Earlier quoted context omitted.

That's in fact often not their core purpose !

... which is why the rest of us should give them, and those who operate them, zero respect . Nobody but AMD gives a fuck about AMD's internal policies or motivations.

I have thought about AMD's security team and their practices once in the past 18 months, and it was this morning, reading this thread. I do not care about AMD or what you think about AMD. AMD has absolutely nothing to do with my point.

Re: The RCE that AMD wouldn't fix

#34
There's two requests involved for the auto updater, one to grab the XML file, and one to grab the driver file over plain http.

If the autoupdater can't handle the redirection when grabbing the XML file, then it's a case of accidental safety by mistake that would prevent grabbing the plain http file.

Re: The RCE that AMD wouldn't fix

#35

The "signature verification" in the fix being CRC32 is pretty hilariously clueless.

Especially because if they had read about or studied this problem they would find tons of prior art where CRC32 was considered not secure for solving the problem. CRC32 solves a different problem -- how do you verify that the data that was received is identical to the data that was sent. It makes no guarantees about who is sending the data, which is the real problem signatures solve.

More specifically, it solves the problem of verifying that the data received was not accidentally corrupted somehow. Unlike cryptographic hashes, CRC32 does not do much to defend against deliberate, malicious modification. It's too easy to craft some different data that matches a given CRC32 value.

Re: The RCE that AMD wouldn't fix

#36
post #6

Such a bug could have been exploited by certain big state actors. Those that have access to international network links. Those that have the ability to generate new firmware that simply passes the CRC32 checksum.

A bug in a nonfunctional autoupdater. Big state actors. Got it.

Re: The RCE that AMD wouldn't fix

#37
AMD's utter incompetence when it comes to the software side of things is truly, truly baffling to me. It's not like you need a mountain of developers, a team or two on the right project would do wonders for their market share.

For example: Implement the CUDA. CUDA's won, hands down, that toothpaste is solidly outside the tube. Luckily, to the outside observer CUDA is just an API, and API's aren't copyrightable. Literally nothing is stopping AMD from hiring a relatively small team of developers to make AMD GPUs CUDA-compatible.

Post reply on HN