Multi billion dollar company, by the way.
I say the same when I dealt with Amazon's website, and to a smaller extent eBay.com. Don't forget Facebook Marketplace.
The RCE that AMD wouldn't fix
101–110 of 131 posts
Re: The RCE that AMD wouldn't fix
#102Earlier quoted context omitted.
> The current installation shall already contain one (or more) public keys that it trusts for updates The current installation was fetched via HTTPS, right? Either by you or in the factory. Just saying the "bootstrapping already happened" does not make it not happen. It still needs to bootstrap trust from somewhere
I still can't figure out what problem you believe needs-fixing or what process you think needs to be explained. My most-charitable guesses are: A. You're asking what should be done if the manufacturer's auto-update server has already been completely compromised by hackers and remains compromised. B. [Implicitly rejected in last coment] You're asking how anybody can guarantee the very first install can be trusted even…
[Followup] To over-communicate in the hope that it somehow resolves things, we already have this chain of trust:
1. Axiom: We trust the current daemon and OS. We must assume this, because otherwise it's an entirely separate problem and this whole discussion of an auto-update channel is irrelevant.
2. Axiom: We trust the owner. Tampering with the local auto-update process is not part of our threat-model, because a user who can do that doesn't need to.
3. The daemon is already coded to trust a replacement/successor installer if it meets certain criteria, which are:
3a. It comes from a trusted domain name it already knows should be owned by the same developer/company.
3b. The remote end is authenticated to "be" that domain via certificates from the (trusted) OS.
3c. The content is protected from tampering due, becauese we trust that TLS/SSL encrypts it.
That all already exists, it does not need to be torn down or rebooted. The proposal here is to simply to harden it with a new requirement in the next version:
3d. The next install must be signed by a trusted key-pair that was shipped with the current install.
This improves trust because it means an attacker would also need to compromise keys held in a release pipeline, which is much easier to secure than a CDN/webserver.
Re: The RCE that AMD wouldn't fix
#103Earlier quoted context omitted.
HIP tries to be like this, almost API compatible with CUDA such that you just need to do find and replace. I think they even had a script to do this for you. But the issue remains that the actual support and debugging tools remain so atrocious that it doesn't help to combat the CUDA monopoly. They've further burned a lot of trust by never really delivering on their promises to do better unless you're a customer large…
HIP was such a self-own and clear demonstration of AMD software capabilities... well, the lack of software capabilities. HIP was hard-coded for one GPU architecture. CUDA did it right, it has a intermediate virtual assembly PTX and driver compiles it to whatever actual instruction set card actually uses. Imagine a meeting where they signed off on that. So each developer will have to provide a different binary for eac…
Yes, that was in part why they've had such a terrible history with GPU support.
They lost me as a customer when they rushed dropping support for the Radeon VII because of the need to ship binaries for every ISA, and didn't deliver proper 5700XT support until it was outdated.
Re: The RCE that AMD wouldn't fix
#104Earlier quoted context omitted.
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.
Computing a CRC is equivalent to attacking it. The checksum is the value that produces a certain fixed constant when appended to the data. This is why you'll often see checksums as the last field in a message. It allows for hardware to verify the entire message by checking if the CRC of the bytes equals that fixed constant without having to parse it.
It's trivially easy to create a malicious file with the same CRC as another file.
So "verifying" using CRC is very stupid if you're trying to prevent malicious execution. You need to use cryptographic signatures.
Re: The RCE that AMD wouldn't fix
#105AMD software is often utter trash. I am a diehard fanboy of their GPUs, and have been since they were still ATI but I had to finally purchase an nvidia GPU because of how bad AMDs software quality is. My powerful 5700XT spent two years basically broken, because the default, driver provided fan curve locked the fan at 27%. For two years, I couldn't figure out why my GPU constantly crashed, because it was overheating,…
There is something wrong with the internal fan curve on my old rx580 as well. I ended up writing a controller to manually set the fan speed via the /sys interface.
I still need to figure out why the internal curve is not working, but have not gotten around to it because I like my controller so much. The novel bit is that as I was writing it I had an epiphany "Why a curve? What we really want is to close the loop. Set an ideal temperature and figure out the fan speed to maintain it" So my controller has a cute little PID loop to do just that. realistically it never works as I imagined. At idle the temp is lower then the set point at the slowest fan speed and at load the full speed fan keeps it ~ 10C higher than the set point(perhaps this means my set point should be higher?). but sometimes I get that goldilocks midrange load and it works great.
Re: The RCE that AMD wouldn't fix
#106AMD didn't deny it was a vulnerability; they denied it was in the scope of the bounty program. Remember that at giant tech companies, the incentive is to pay out bounties --- there are people on the vendor's team whose performance is measured in part by how much the program pays out.
How do we know the incentive is to pay out bounties? And how do we know that doesn't change on the whims of the management chain?
We don't "know" anything unless we are at that company in particular and part of the management conversations. We at best can theorize based on incentives, but that's assuming companies and people are logical, which is a large assumption. I could easily see someone in the midst of layoffs and reduction of overhead initiatives thinking that the solution is to convince everyone you do payouts, but actually minimize payouts, which you could do by creatively using scopes.
Re: The RCE that AMD wouldn't fix
#107AMD didn't deny it was a vulnerability; they denied it was in the scope of the bounty program. Remember that at giant tech companies, the incentive is to pay out bounties --- there are people on the vendor's team whose performance is measured in part by how much the program pays out.
How do we know the incentive is to pay out bounties? And how do we know that doesn't change on the whims of the management chain? We don't "know" anything unless we are at that company in particular and part of the management conversations. We at best can theorize based on incentives, but that's assuming companies and people are logical, which is a large assumption. I could easily see someone in the midst of layoffs…
You're right. AMD could for some reason be unlike every other major tech company that runs a bug bounty. Maybe AMD stood up a public bounty where people get their pay docked when bounties get paid, rather than perfed up. They would potentially save, say, 0.000289% of their annual revenue, in exchange for stories like these. Checks out.
Re: The RCE that AMD wouldn't fix
#108Earlier quoted context omitted.
Computing a CRC is equivalent to attacking it. The checksum is the value that produces a certain fixed constant when appended to the data. This is why you'll often see checksums as the last field in a message. It allows for hardware to verify the entire message by checking if the CRC of the bytes equals that fixed constant without having to parse it.
It's trivially easy to create a malicious file with the same CRC as another file. So "verifying" using CRC is very stupid if you're trying to prevent malicious execution. You need to use cryptographic signatures.
The entire point of my post was that it's trivial, exactly as difficult as computing the CRC in the first place. Not sure why that was controversial.
Nevertheless, they're still useful protection against noise, and you usually want to detect it right as you're pulling protocol messages off the wire. Placing checksums in the last field of each message (as Ethernet does) simplifies the hardware implementation.
Re: The RCE that AMD wouldn't fix
#109Earlier quoted context omitted.
MITM where attacker needs to install their own CA certs on the victim's device -- sure, out of scope. MITM because you used http instead of https and you don't have any other verified cryptographic signature on your data -- get tae fuck, fix it pronto.
I'd even count this as "having local access to the device", as that is what is needed to install such a cert
The list of preinstalled CAs is long. I think its a safe bet that many nation-states have covert control over at least one CA on that list. (Or they have one of the root signing certs). HTTPS is way better than HTTP. But I'd personally rather if these random organisations didn't have RCE on my computers.
I've never heard of most of them. AAA Certificate Services? AC RAIZ FNMT-RCM? ACCVRAIZ1? Actalis? AffirmTrust? Even Godaddy is in there. I know I don't trust those guys.
Trust has gotta start somewhere. But its much better to TOFU, then pin signing keys in the updater.
Re: The RCE that AMD wouldn't fix
#110The last time I remember, the green company did the same HTTP thing literally with their driver downloads from the website, and refused to fix it.
Makes me wonder, how much of that 4 month delay was spent deliberating with the state actor. As if there was Prism, and both companies were legally bound to allow MitM to happen, and thus don't have a bug bounty for it.