The "signature verification" in the fix being CRC32 is pretty hilariously clueless.
Given the way AMD has been treating this issue, I'm assuming they're just incompetent, though.
31–40 of 131 posts
The "signature verification" in the fix being CRC32 is pretty hilariously clueless.
Given the way AMD has been treating this issue, I'm assuming they're just incompetent, though.
Earlier quoted context omitted.
That's in fact often not their core purpose !
What is it?
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.
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.
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.
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.
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.
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.