So how does AMD prevent downgrade attack? The hardware will still authenticate and load the vulnerable Firmware. Sorry AMD, problem only partially fixed...
AMD has finally weighed in with its opinion of the security flaws in its Epyc, Ryzen, Ryzen Pro, and Ryzen Mobile chips, identified in a rather over-the-top fashion by CTS-Labs a week ago. The vulnerabilities affect the firmware managing the AMD Secure Processor and the chips used in some socket AM4 and socket TR4 desktop …
No, I don't work for CTS. I'm a random bloke that hates the way AMD has made us all rental users of their poorly designed PSP software. I was a huge fan of the Opteron series back in the day, before AMD followed Intel down the dark closed path. Nowadays I try not to use x86 of any sort because both vendors have decided that we, the users, should not be trusted with full control of our computers.
Imagine a world were we could simply say "you know, that PSP is a risk. I'll just change the code to shut it down since I don't care about the DRM features it provides.". But no, AMD doesn't want that to be possible, and actively prevents it. That's my main point of contention with AMD.
This CTS thing has really brought the AMD fanbois out of the woodwork. Enjoy your rental CPUs, guys, I'm off the x86 train for good reason...
Not so much Brand Lemmings as you put it as Intel is just as bad but what I downvoted you for was your almist instant dismissal of AMD Patches before they have been released. To many that sounds like Trolling.
Yes you have a bone to pick with AMD. I'm sure that you aren't alone in that but others might be willing to give AMD the benefit of the doubt until the quality of their patches can be reviewed.
Intel is not squeaky clean wrt patches as we all know.
I may never buy an X86 powered device or cpu ever again. Most of my computing needs these days can be met by a Raspberry Pi 3. YMMV.
Isn't the RPI the one that loads a binary blob, which you don't have source access to, before it loads the kernel and boots your OS of choice? Not as locked down as x86 but not the holy grail of open either.
I agree to an extent about the PSP. I'd be fine with it as-is if we had the ability to completely disable it from the BIOS.
However, your first post was highly inflammatory in claiming that the patches were useless when we have virtually no information on them, and they're even still coding them.
Hence my somewhat facetious question about you working for CTS.
@ Byron "Jito463"
I don't think I did a good job of explaining the concern, apologies for that. Since the vulnerabilities require root anyway to be exploited, I don't think the main concerns change for the PSP part of the patches. For the ASMedia stuff, which affects a whole ton of systems including Intels', the patches may at least have some positive effect.
I keep forgetting there were a bunch of additional claims beyond arbitrary code execution on the PSP. That's the only one that scares me; anyone with any sense on security doesn't send secure data unencrypted over the chipset (i.e to disk, network, etc.) anyway.
OK, great! Let's assume no one got root on your particular install by conventional means (zero day, phishing, etc.). How are you verifying no one inserted these flaws in your firmware before you got the computer? Because if they did, they've got root already and you don't even know to look for the intrusion...
BTW the same issue exists with Intel's products and the ME. Intel is NOT the answer here.
How are you verifying that the microcode zero days were not on the machine before you acquired it?
Donkeys years ago I worked in a company that made mission critical hardware. We used a checksum on the software/firmware code at compilation time.
The checksum values were stored on hard copy (paper) and elsewhere, corrections to any errors were signed (on the sheet of paper). An altered entry with no signature was deemed invalid : that software release was checked against the version controlled code library.
The binaries generated were then stored on a server and loaded onto the EPROM devices as required.
When programmed the EPROM was interrogated to verify that the checksum was correct. Verification was against the paper copy checksum.
The devices were not connected to any external networks and could not be interfered with (exception : physical modification).
There has to be a point where trust can be established. If not what remains is the belief that the manufacturers are deliberately compromising their firmware.
The weak point is the initial compilation, mitigated with a code comparison by a third party.
We've already seen Lenovo et. al. deliberately compromise their own firmware for financial gain. I don't think trust can be established at that level in the current day and age, sadly, unless you happen to have a signed agreement with the vendor where they take financial liability for any malware / bugs present in the firmware you're not allowed to see or touch....
@ stuff and nonesense
Exactly! But now you have AMD and Intel both saying they have this wonderful ME/PSP solution so that you don't have to do that kind of low level check any more. Then we find out their "solution" is completely broken, but now we can't even really get the golden hashes required to verify the firmware since UEFI only updates chunks of what's actually on that Flash device (or devices).
Bad situation all around, brought on by ever increasing DRM strategies and pure greed by Intel and AMD....
I think you're missing a few things here. Before I continue, let me make you aware that I also despise our continued inability as end users to disable/remove these amenities.
Intel Management Engine and AMD Platform Secure Processor are not just intentional spy tools funded by the NSA, MI6, Kremlin, and every other relevant international agency, but provide essential sysop facilities that let you easily control hosts of machines without access to the underlying operating system. As far as trying to mitigate attack vectors, I have never personally seen that claimed by Intel, although I don't know what AMD's stance on it is.
You sound a bit like a loon, even though I agree with you. If you want people to listen to you and want a proper discussion, you might try coming off more nice, and not posting so much. No one likes an angry conspiracy theorist.
Again, not defending ME/PSP, as I also want them gone, or at least open.
I guess it must be a matter of perspective but once something _is_ potentially a spy tool I don't care whatsoever whether it can or cannot be anything else. I just want it off my system.
That would be pretty much everything then? Pretty much everything is potentially a spy tool.
One has to have a level of trust somewhere, but swivelling eyes and tin foil hats don't do much and it's usually the simpler spy methods that are still in use because they are easy and still work.
Are you so worried about keyloggers that you vet the OS and track what happens to every key press and where the message is relayed, including checking canary network traffic to see if key presses affect it in unexplained ways? That's nice, all it takes is a USB key logger which passes through the USB identification and includes a dirt cheap 3G mobile comms chip in it and all that effort is for nothing - these kind of USB key loggers are disturbingly common and nothing in the OS will be aware of it. This is just one relatively rare tech example and the most likely route of loss of data is still the human factor. i.e. printing the data and not destroying it appropriately, copying the data, just having weak passwords (who needs to hack a system and go to all that trouble when somebody has a weak password or shares it?).
Point taken. This is an issue I've been fighting with for years, so I can get a bit fired up about it.
On the remote access side, though, the thing is you don't need that kind of God-mode access to the core of the system to have a perfectly functional remote access solution. That's the odd design that raises eyebrows; before the ME/PSP (and even now) there are very functional standalone BMC solutions, and even some open ones such as OpenBMC. You don't need the ability to watch and control things below the OS and hypervisor unless you're after some very intrusive DRM goal or just plain spying on the owner.
"How are you verifying no one inserted these flaws in your firmware before you got the computer?"
Isn't that a fairly universal problem? Intercept the item in transit and replace the firmware? I seem to remember stories about the NSA putting custom UEFI on motherboards and firmware on HDDs (granted, you would hope that the various programming routines on the board would require the new firmware to be signed and validate that signature prior to loading it, but ... ) ...
The ME and PSP were introduced (and the machine locked out of owner control) specifically so that this kind of attack would be thwarted. Now we're in the insane position of still having to worry about this kind of attack (which the ME and PSP flaws have made reachable by nearly any motivated hacker) AND we're locked out of our own hardware "for safety reasons".
Basically, the only justifiable reason for these black boxes to be present has failed, and the vendors are still insisting on keeping the machine owners from having full control. How is this situation even remotely acceptable?
Whitepines, that is a good point. People always assume the attack will happen once the machine goes live but tinkering with it before it's delivered would be a powerful attack. We recently had questions about the security of Supermicro machines because they are Chinese. This then changed into someone adding tiny chips to the motherboard. That whole business seemed odd but it did expose the idea that the machines could have been altered on route to the customer.
I think proper physical security of the packaging would help but then the route in would be a customs inspection. Just boot the machines to a a USB stick and insert the firmware changes.
I'm not sure how reliable that would be as a compromise since most people grab the latest firmware before installing the OS. I'm not sure if microcode stays in the CPU or is loaded at boot time. It's obviously the sort of thing very security conscious people would know to check and ordinary computer builders would never think of.
I realized that I was somewhat more inflammatory than intended here. I'm only referring to the PSP vulnerabilities here, the other vulnerabilities are likely fixable with proper patches. The PSP stuff is more of a design flaw than anything else, a design flaw shared across Intel and other vendors. Basically, the problem is that with the central vendor-controlled firmware signing schemes, once a single ME/PSP version is cracked the entire useful purpose of that processor (preventing unauthorised code from booting on the low level firmware side) is gone, leaving only the DRM and other restrictions that harm the end user.
IMNHO the CTS claimed AMD CPU flaws are nothing more than a smoke screen to divert attention away from Intel's decades long production of defective CPUs that cannot be repaired via microcode because Intel chose to violate command security protocol. With CTS spreading FUD Intel can claim AMD's products also have security issues when they do not. Allowing CTS to get away with these bogus claims would be an injustice, especially if there is also a stock price manipulation scam in association with a stock market analytics firm claiming AMD stock is worthless and that AMD will be declaring bankruptcy - NONE of which is true. It will be interesting to see what the judicial system decides regarding this charade.
I don't understand why people think this is a conspiracy by Intel to discredit AMD. Intel has no need to do such a thing. I like AMD(was a pretty hard core fan of Opteron 6xxx at the time, have several still in use), and I really don't care about these security issues with their chips I agree there are bigger fish to fry.
Intel isn't going to go down much at all by these security issues in their chips, nor is AMD. Why anyone would think otherwise I just don't understand.
Now that the "horse is out of the barn" on cpu security stuff I'm sure we will be seeing quite a bit more security issues in the future. I think Intel put out a big bug bounty for other such bugs but I swore I thought I read that it ends at the end of this year or something, which if so makes no sense to me.
And absolutely this AMD security thing was a poor attempt to manipulate the stock - so what ? They were up front about it saying they may have a financial interest in it. The attempt failed horribly, AMD's stock is about the same as it was at the beginning of the year, and Intel's stock is higher since November, started going up early last month (looking at yahoo finance I don't track stocks myself), long before this AMD stuff happened. I think I even read on the day of the big "announcement" against AMD their stock actually closed higher than the previous day.
Both the announcement of the security issues and the backlash from many folks is just so overblown.
Also anyone in a position to be talking to Intel directly about their processors is going to be a very big knowledgeable organization simply on scale alone. Such an organization would see right through any feeble attempt by Intel to point a finger at AMD on these issues to try to claim anything meaningful against them.
Also from a stock "manipulation" standpoint from what I read CTS did nothing illegal. There is no insider information. As someone wrote that I read recently if the law were to go after CTS it would be very bad in that it would send a sign - don't look too close at a company to find issues or you may go to jail. The law seems pretty clear, and the disclaimers are right there saying they had financial interests in the stock. Seems everything is above board assuming there wasn't insider activity (AMD employees giving CTS the flaws), which from what I have read is not the case.
@Nate, I agree with you for the most part. Although that somebody shorted AMD stock to coincide with the press release from CTS and issued a stock warning within an hour or so of the CTS press release is a little fishy.
More importantly, a lot of the errors are in AS Media chips, which have been customized for the Ryzen/Epyc family of processors, but CTS first found the flaws in discrete AS Media chips, which are used on Intel motherboards, as well as AMD non-Ryzen motherboards, the chips contain the same backdoors as those in the AS Media custom chipset for Ryzen, yet this part of the story seems to go under in the press.
It might or might not be an Intel hatchet job, I'd say probably not, but the bias by CTS and in the press towards it being an AMD problem and not a problem with AS Media in general is worrying.
Is there a problem with AMD chips? It certainly looks this way and AMD have confirmed the problems.
Is this purely an AMD problem? No, the major part of the story is backdoors in AS Media chips used on many non-Ryzen motherboards having a backdoor and AMD had AS Media incorporate the functionality of these chips in a custom chipset for them and AS Media also incorporated their existing backdoors into those chips.
Is it limiteed to AS Media? Looking at the CTS reports, they have found errors in Ryzen/Epyc beyond the AS Media issue, but they muddy the water.
So, why is everything concentrated on AMD? Surely AS Media should be the ones facing the majority of the flack? Surely they should be the ones having to issue firmware upgrades for Intel and AMD based mainboards containing AS Media chipsets?
Yet CTS and the press seem to make it sound like if AMD "get their act together" and patch Ryzen and Epyc mainboards, all those Intel and AMD non-Ryzen boards will also magically heal themselves... :-S
A lot of the people sticking up for AMD are doing so because these flaws have been blown out of all proportion, and have been disclosed in a manner designed to try and cause maximum financial damage to AMD. The whole point of researching flaws in software/hardware products should be to allow them to be fixed to improve security, not to try and make a quick buck by blowing them out of all proportion whilst crapping on the companies involved so you can short-sell their stock. Whatever your thoughts on the flaws, CTS's conduct regarding the disclosure of these flaws absolutely stinks.
Had the typical process been followed (flaws disclosed to AMD to give chance for patches to be developed first), these flaws may well have been easily patched long before public disclosure - in which case, no big deal at all. After all, pretty much all complex software and hardware systems will contain security flaws that are identified and mitigated over time.
They even went to the level of calling one of the flaws "RYZENFALL". Again, a deliberately inflammatory name designed to try and damage AMD's brand.
When a firm attempts to profit from security issues in this manner, they deserve all the stick they get.
AMD share price was at $11.64 before the CTS hatchet job started. It's now at $11.11 if you beleive the result of typing "AMD Share price" into Google so the AMD share price has fallen, and not risen.
Does anybody know how what CTS needs to reduce the AMD share price to in order for their scam to make them a profit?
AMD CPUs do NOT have defects per se. The only means to implement any alterations to the secure area of the CPUs is with full administrative permissions so the CTS claims are meritless. What has been disclosed is that there was a 15 million share short sell of AMD stock at the time of the CTS Labs public disclosure. You can be certain that some crims are going to be spending a lot of time in the Iron Bar Hotel and their ill gotten profits confiscated. This deal smelled from the get go with CTS only giving AMD 24 hours notice. Let's hope all involved pay for their criminal activity.
Biting the hand that feeds IT © 1998–2020