AMD shares mitigation plans for Zen chipset security flaws

[CAT-THE-FIFTH]

deflection by using the internet rant defence so can avoid reading anything

Three people have told you so far,not just me.

I also see where you are going with this - somewhere else someone did the same and people kept asking him REPEATEDLY to prove Intel was not affected in a similar way,and after probably the better part of 10 pages of arguing - nothing came up,he ended up calling people things and then left(I saw where it was going so didn't bother). Another chap tried it even with Linus Torvald and David Kanter too,and the response was very funny.

I am not going to get involved in this,as I predict I will most likely link a 100 more articles,and then it will go around in circles - if you can't get what I am saying,then read the earlier posts I made again. If you CBA,its not my issue TBH and believe whatever you want.

I have already asked for your evidence to show Intel ASMedia chips are not affected - you have provided none.

The only reason this is even an "issue" is that AMD were given less than 24 hours to act over this.

Intel has been given months to patch its issues,but most people looking out there,will call it for what it is,just a company trying to blindside AMD for financial gain.

If AMD had the same amount of time Intel had,we would not have heard much about this.

Got any evidence that they don't? Everything I've read says the attack targets the Promontory chipset, which is - as CAT has already pointed out - is connected to the processor via a simple PCIe x4 link. If it can be compromised to read physical memory, there's absolutely no technical reason to think that any ASMedia chip that exposes the same flaw ... which is apparently all of them ... couldn't be exploited the same way. Indeed, it makes no sense to raise the issue that those ASMedia chips have similar firmware unless that was a factor in the attack working ... which would strongly imply that all ASMedia chips can be targeted.

What you think is kind of irrelevant; unless there's hard evidence of the attacks not working against Intel targets it's perfectly reasonable to question why AMD are being singled out for this. I've seen nothing from CTS about testing these vulnerabilities on Intel boards. Happy to be pointed in the right direction if that information exists.

It gets better:

[W]e have started researching ASMedia chips about a year ago. After researching for some time, we have found manufacturer backdoors inside the chip which give you full control over the chips (ASM1042, ASM1142, ASM1143). We wanted to go public with the findings, but then saw that AMD have outsourced their chipset to ASMedia. So we decided to check the state of AMD, we bought a Ryzen computer, and whimsically ran our exploit PoC, and it just worked out of the box.

Regarding the chipset, there you actually have vulnerabilities that affect a range of products. Because as we explained earlier, we just looked first at AMD by looking at ASMedia chips. Specifically we were looking into several lines of chips, one of them is the USB host controller from ASMedia. We’re talking about ASM1042, ASM1142, and the recently released ASM1143. These are USB host controllers that you put on the motherboard and they connect on one side with PCIe and on the other side they give you some USB ports.

What we found are these backdoors that we have been describing that come built into the chips – there are two sets of backdoors, hardware backdoors and software backdoors, and we implemented clients for those backdoors. The client works on AMD Ryzen machines but it also works on any machine that has these ASMedia chipsets and so quite a few motherboards and other PCs are affected by these vulnerabilities as well. If you search online for motherboard drivers, such as the ASUS website, and download ASMedia drivers for your motherboard, then those motherboards are likely vulnerable to the same issues as you would find on the AMD chipset. We have verified this on at least six vendor motherboards, mostly the Taiwanese manufacturers. So yeah, those products are affected.

Thats from Extremetech and AT - so they even said all ASMedia chips of that line are affected. They just "randomly" decided to look at AMD:

If CTS Labs has accurately characterized these flaws, the problems in Asmedia controllers affect millions of Intel motherboards worldwide going back six years. In the early days of USB 3.0, before Intel added its own native chipset support, Asmedia was one of the most common third-party providers. Chips like the ASM1142 are still used on Intel motherboards today. When we looked at Newegg, nearly every USB 3.0 PCI Express card we spot-checked used an Asmedia solution — typically the ASM1042 or ASM1142.

It seems a bit odd for a company looking into ASMedia related flaws to then turn their focus onto AMD’s secure processor, using the chipset vulnerabilities as a pivot point. ASMedia chips, especially the USB host controllers cited by CTS-Labs, are used on literally tens of millions of Intel-based motherboards around the world, from all the major OEMs. For a large period of time, it was hard to find a system without one. The decision to pivot on newer AMD platforms is a weak argument, the wishy-washy language when discussing projects at the start of the company’s existence, and the abrupt ending to the call when asked to discuss the original customer could be construed (this is conjecture here) that the funding for the product was purposefully directional towards AMD.

Interesting they never bothered to make an ASMediaFLAWS website??

This is why AT thought it was so weird they ignored Intel.

When I set up my new laptop one of the first things it wanted to do was update the BIOS - not unexpected given the Spectre/Meltdown mitigations, but I was surprised to note that at the same time it also updated the firmware for the USB 3 controller. Curious coincidence, don'tcha think?

According to them they are the first to find some issues,so if you are implying there are fixes for Intel,it means they were informed first before AMD and with sufficient time to act.

Very marginal if true!! Not if you are CTS-Labs,so who is this mystery client who commissioned the work??

When AT asked them they suddenly ended the interview and stopped answering any further questions AT sent them.

As AT has the second largest web traffic of any computing site out there,it seems a bit of an own goal.

[Corky34]

Got any evidence that they don't? Everything I've read says the attack targets the Promontory chipset, which is - as CAT has already pointed out - is connected to the processor via a simple PCIe x4 link. If it can be compromised to read physical memory, there's absolutely no technical reason to think that any ASMedia chip that exposes the same flaw ... which is apparently all of them ... couldn't be exploited the same way. Indeed, it makes no sense to raise the issue that those ASMedia chips have similar firmware unless that was a factor in the attack working ... which would strongly imply that all ASMedia chips can be targeted.

No because like i said when i started this conversation it's difficult to know for sure what with the lack of technical details, i thought I'd made it pretty clear it was based on my understanding, that was before Cat decided to take things of on a tangent and started attacking me for saying things i didn't say.

Getting back OT: Yes the attacks do target that chipset but like i said the PSP is meant to prevent the flashing of unsigned firmware, bootloaders, and drivers (aka:rootkits) and it didn't block the installing of unsigned firmware (if you have the patients to sit through one of CTS-Labs POC videos they released you can see them flashing an unsigned modified BIOS file by using PSexec from a remote terminal, something the PSP should have prevented). It's not only the ASMedia chips that can be targeted, any ASIC can, and that's why both Intel and AMD designed in safeguards to prevent the use of unsigned firmware, bootloaders, and drivers.

What you think is kind of irrelevant; unless there's hard evidence of the attacks not working against Intel targets it's perfectly reasonable to question why AMD are being singled out for this. I've seen nothing from CTS about testing these vulnerabilities on Intel boards. Happy to be pointed in the right direction if that information exists.

No i don't think it's irrelevant, like i said and both you and CAT seem to be ignoring I'm basing this on my understanding and that it's difficult to know for sure what with the lack of technical details, however one would assume that the reason AMD has been singled out and not Intel is because you can't flash unsigned firmware to Intel platforms when you enable their equivalent of device guard and that's already been tested on many occasions.

When I set up my new laptop one of the first things it wanted to do was update the BIOS - not unexpected given the Spectre/Meltdown mitigations, but I was surprised to note that at the same time it also updated the firmware for the USB 3 controller. Curious coincidence, don'tcha think?

No, because BIOS updates contain more than a single file, they're a collection of ROM modules for updating any or all firmware attached to a system.

Three people have told you so far,not just me.

So might makes right then.

I also see where you are going with this - somewhere else someone did the same and people kept asking him REPEATEDLY to prove Intel was not affected in a similar way,and after probably the better part of 10 pages of arguing - nothing came up,he ended up calling people things and then left(I saw where it was going so didn't bother). Another chap tried it even with Linus Torvald and David Kanter too,and the response was very funny.

No you don't because you're hung up on some kind of assassination attempt, I'm trying to discuss what we know about the actual exploits and i don't need to prove Intel are not effected because everyone knows they're not, because, and I'm going to put this in bold in the hopes that it sinks in, because the world has been testing Intel's equivalent for years, if you enable Management Engine, Server Platform Services, or the Trusted Execution Engine in the BIOS and people could remotely install unsigned, modified BIOS don't you think someone would have spotted that by now?

I am not going to get involved in this,as I predict I will most likely link a 100 more articles,and then it will go around in circles - if you can't get what I am saying,then read the earlier posts I made again. If you CBA,its not my issue TBH and believe whatever you want.

The reason i CBA is because you're doing what you normally do, quoting a wall of text from what someone else said and attacking them for something they didn't say.

I have already asked for your evidence to show Intel ASMedia chips are not affected - you have provided none.

You don't need evidence it's simple logic, like i said I'm going on my understanding and if you took the time to try and understand how these exploits work instead of getting hung up on how awful CTS-Labs are, how wrong everyone is apart from you and looking at AMD through rose tinted glasses then maybe you'd understand why it doesn't effect Intel.

But just in case you missed it here it is again: Because Intel's Management Engine, Server Platform Services, or the Trusted Execution Engine prevents the installation of rootkits (unsigned, modified, firmware, changes to the MBR/bootloader, and drivers) and AMD's PSP does not in a particular circumstance, that's not something that needs testing on Intel platforms because (afaik) it's common knowledge that they prevent installing of unsigned software into hardware once that feature is enabled in the BIOS.

The only reason this is even an "issue" is that AMD were given less than 24 hours to act over this.
<going of on a tangent again>

There you go again with walls of quotes and focusing on how the exploits where announced rather than the actual exploits, that once again I'd like to remind you AMD have said do exist.

According to them they are the first to find some issues,so if you are implying there are fixes for Intel,it means they were informed first before AMD and with sufficient time to act.

And if you got of your high horse for a moment you'd be able to understand why there are no fixes for Intel (hint: It's because when the security feature that prevents installing unsigned/modified firmware, drivers, or bootloaders is enabled you can't install unsigned/modified firmware, drivers, or bootloaders so you don't need to fix something that's not broken)

I didn't want to post it as i don't want to give CTS-Labs any credit, views, or anything, however if you can stomach watching it here is their POC video.


If you can't understand that you shouldn't be able to remote into a system and update its BIOS when secure boot is enabled then IDK what else to say.

[DanceswithUnix]

I didn't want to post it as i don't want to give CTS-Labs any credit, views, or anything, however if you can stomach watching it here is their POC video.

That really didn't explain much. So it isn't a remote attack (they pulled up a shell from another machine because the server allowed it, it wasn't part of the actual attack), and exactly as claimed in their original announcement they defeated the security signatures. I'm left with more questions than answers at the end of that though, like whether that BIOS was crafted for that machine or would work on any Ryzen box; whether the PSP had a new public key injected into it to make the BIOS look legit. Or is it simply that the DOS utility knows nothing about signing and just writes to the flash directly?

It's still hard to get excited though. Intel's remotely exploitable management problem (so way worse than this) a year ago went unpatched for some 7 years, at the end of which is was estimated only 6258 servers were vulnerable. (https://arstechnica.com/information-...-for-10-years/ )

I used to design pinpads, where secure boot is an absolute thing and every single runnable file in the system needs a signature if it wants to do anything clever. PCs don't have that, specially under Windows, so when the trust chain is broken so early and so often as a matter of course the idea that the trust chain can be broken a bit earlier isn't that interesting. Personally, I just turn secure boot off as I consider it a worthless irritation, but then I have never installed Windows on a server so perhaps I have a non typical view.

[Corky34]

Totally agree that it leaves a lot of unanswered questions, i wasn't trying to explain or provide a complete break down, it's just the impression i got from watching it is that there is some way to defeat the checks that i would assume the PSP is meant to carry out to prevent installing rootkits.

I'd like to add, to avoid any further witch hunting, that I'm not saying this is any worse or better than previous Intel ME exploits or that CTS-Labs have been responsible in the way they disclosed things, I'm simply talking about, from my understanding, what the exploits seem to be.

The thing that makes me laugh about this whole thing is that before PSP and ME security checks intended to prevent the installation of some unauthorised software doing that was the de facto way PC's operated and now a failure of those checks is seen as bad.

So it isn't a remote attack (they pulled up a shell from another machine because the server allowed it, it wasn't part of the actual attack), and exactly as claimed in their original announcement they defeated the security signatures.

Just on this specific point, it is though isn't' it? If as they say the attacks need admin rights doesn't that (by default) allow remote access, as in all Windows machines allow someone with admin rights to login to them remotely and access the administrative shares.

[DanceswithUnix]

Just on this specific point, it is though isn't' it? If as they say the attacks need admin rights doesn't that (by default) allow remote access, as in all Windows machines allow someone with admin rights to login to them remotely and access the administrative shares.

No, a remote attack means I can take out the machine from cold without any valid login credentials or being in front of it.

This is an attack performed locally on the command line of the machine, it just happened in that video that they were using remote access to run the command. That is what people are indignant about, if you can log into a machine and run admin commands then you already own it and this doesn't buy you anything. The upshot of Masterkey is that if your server is hacked you used to blank all the drives and reinstall or recover from backup, now you also need to reflash the BIOS or there might be a backdoor left in the PSP by the attackers.

Edit: A remote attack tends to run something like this: Say you are running a badly written web server. The programmer has decided that a URL will never be more than 4000 characters and they stick that as a limit in a local array in their program and then they don't check when copying the URL from a web browser request to see if it is bigger than their array. Someone spots this, and they very carefully craft a URL that is say 4100 bytes long so that fills the array, goes off the end and writes over the return address. When that bit of code is called by the web server, instead of returning to the calling routine in the web server the attacker has smashed the stack so that the return jumps a payload of machine code which makes up part of the URL they sent which instructs the web server to run some shell script. Now your web server has downloaded and run a rootkit which can open a remote login port for the attacker to use as a back door. The upshot: Thanks to a programming error someone who should only be able to access a web page hosted on your machine can now get remote access at whatever privilege level the web server runs at.

That was how it would work about 20 years ago anyway, these days you would expect the stack to not be executable so the payload won't run, the programmer should run analysis tools to warn of the possible array overflow, the payload is hard to write because of address randomisation, and the server should be in a DMZ behind a firewall so the open port can't be accessed.

[Corky34]

That's not the definition of remote attack that i recognise and although not authoritative wiki doesn't say anything about not having login credentials, it simple defines it as "A remote exploit works over a network and exploits the security vulnerability without any prior access to the vulnerable system" and if you knew or had the administrator password you could carry out these exploits over a network from what they describe and what i saw in the video.

[Tabbykatze]

That's not the definition of remote attack that i recognise...

Heartbleed was a remote exploit and is pretty much what was described. All malicious activity is an attack, please don't get hung up on semantics

[watercooled]

I think the problem people have with it was the language used, saying things along the lines of it being 'as bad as it gets' which is just nonsense. It leads me to suspect they're being deliberately sensationalist or don't actually know what they're talking about, suggesting perhaps they're acting as a middle-man between those who 'found' it and the media, because the first party wants to remain anonymous.

It's just not on par with any release I've ever seen from an unbiased, knowledgeable source. As plenty of people have said, both on forums and in the press, something just smells wrong with it. It's not in the public interest to act in the way they did, nor does it make much sense. Finding such an exploit requires *some* expertise, so this entity being both the one to find the exploit, and the ones to be making such weird claims, doesn't really add up.

Don't get me wrong, it's not nothing, but I'd kinda expect those who found it to actually understand its severity.

[Corky34]

I'm not sure they could have handled it any worse, this will probably be held up as an example of what not to do when you discover a vulnerability for many years.

Heartbleed was a remote exploit and is pretty much what was described. All malicious activity is an attack, please don't get hung up on semantics

I could say please don't try constructing a strawman as i said remote attack, not just attack, but saying that feels like I'd be repeating myself as constructing strawmen seems to have been a trend in this thread.

[Xlucine]

That's not the definition of remote attack that i recognise and although not authoritative wiki doesn't say anything about not having login credentials, it simple defines it as "A remote exploit works over a network and exploits the security vulnerability without any prior access to the vulnerable system" and if you knew or had the administrator password you could carry out these exploits over a network from what they describe and what i saw in the video.

If knowing the admin password doesn't count as prior access then everything connected to the internet is vulnerable to this class of remote attacks

[watercooled]

I'm not sure they could have handled it any worse, this will probably be held up as an example of what not to do when you discover a vulnerability for many years.

It's hardly a revelation - it's been a commonly accepted practice to give the people able to fix exploits reasonable time to do so, with an exception being some types of zero-day i.e. where it's being actively exploited and notifying both users and more malicious actors is on-balance less severe than maintaining the status quo until a fix is pushed out. 24h is plain absurd - it's not nearly as critical as they made out, nor did they have any reason to believe it was being actively exploited (certainly no more so than the compared but totally different speculative execution exploits hitting the headlines recently, nor any other exploits which are responsibly reported to companies on a daily basis) so there's no excuse for acting the way they did. They knew exactly what they were doing. That's further reinforced by the fact they went back on their claims to not release proof of concept, supposedly to protect the public.

Following that standard practice by doing the decent, responsible thing and giving AMD reasonable notice, AMD would have most likely readied and began pushing out updates before it was widely known about - no big deal, like the security updates fed to Windows every Patch Tuesday. Instead, what they have created is a window in which the exploit is known about but no fix available. Responsible, eh?

[Corky34]

If knowing the admin password doesn't count as prior access then everything connected to the internet is vulnerable to this class of remote attacks

Well it doesn't, if i told you my password was 123 I've not given you prior access, if i exploited a bug that gave me higher privileged access I've not had prior access, if i do anything short of taking advantage of an existing exploit to leave a way into a system for use at a later date or being physically in the same room at the device then I've not had prior access.

It's hardly a revelation

I know it's not, i only mentioned it because people seem to think it's necessary to keep bringing it up instead of discussing the actual exploits themselves in a thread that is meant to be about AMD sharing mitigation plans for Zen chipset security flaws.

[DanceswithUnix]

Well it doesn't, if i told you my password was 123 I've not given you prior access, if i exploited a bug that gave me higher privileged access I've not had prior access, if i do anything short of taking advantage of an existing exploit to leave a way into a system for use at a later date or being physically in the same room at the device then I've not had prior access.

OK I think this is getting a bit silly with the wording, but Wikipedia's use of the word "prior" is misleading here.

If I guess, hack, social engineer or otherwise get you to tell me your password and I get a shell onto your system, then I am attacking it locally. If I have no need of a password then it is a remote attack.

In this case it is a clear cut local attack requiring a login. No grey area, it is a clear pre-requisite of the attack. No trying to weasel out of how or when the login was acquired, any login counts. A remote attack does not require being logged in.

These attacks tend to build up in layers. An attacker finds a weakness which gets them some sort of executed code on the machine, though normally not at admin level. That code can open a back door onto the machine which lets the attacker download and run more code with the aim of escalating their privilege level up to root/admin. If they get root, they install whatever they want. On the surface that might make what is going on look a bit confusing, but just break it down. This is how I would expect some bad person to deploy Masterkey: A remote attack gets you code execution and rootkit install, the rootkit gets you privilege escalation through local attacks and creates a backdoor login. At that point someone can log in and run Masterkey. In this scenario the first attack was remote, but that was just to peel back the first layer of defense and after that all attacks were local ones.

[Corky34]

OK I think this is getting a bit silly with the wording, but Wikipedia's use of the word "prior" is misleading here.

If I guess, hack, social engineer or otherwise get you to tell me your password and I get a shell onto your system, then I am attacking it locally. If I have no need of a password then it is a remote attack.

In this case it is a clear cut local attack requiring a login. No grey area, it is a clear pre-requisite of the attack. No trying to weasel out of how or when the login was acquired, any login counts. A remote attack does not require being logged in.

We're going to have to agree to disagree on the definition of remote access then as in my book if you're typing "net use \\10.0.01\C$ /u:Builtin\Administrator *" into a local command prompt you're using the network to access the hidden C drive share on a device with that IP, you're connecting to another computers shared resources.

[Tabbykatze]

We're going to have to agree to disagree on the definition of remote access then as in my book if you're typing "net use \\10.0.01\C$ /u:Builtin\Administrator *" into a local command prompt you're using the network to access the hidden C drive share on a device with that IP, you're connecting to another computers shared resources.

What you have described is a remotely executed action with local access rights and therefore will be classed as local administrative access. You need to separate the action from the activity, the initiation may be done remotely but the actual effects are local.

Using the example of heartbleed again, that is a remote attack in the truest sense of the word as you did not need any local permissions to action it.

You may want to agree to disagree but you are being deliberately obtuse about the definitions and the "arguments" in this thread.

I could say please don't try constructing a strawman as i said remote attack, not just attack, but saying that feels like I'd be repeating myself as constructing strawmen seems to have been a trend in this thread.

I don't understand the principle you're trying to get across calling what I've just said as a "strawman". It feels like you're not comfortable with what you're saying being contested by others or having what you're saying getting corrected. If you want to call what I've just spoken about as a "strawman", you can do you and I'll do me.

[Corky34]

I don't understand the principle you're trying to get across calling what I've just said as a "strawman". It feels like you're not comfortable with what you're saying being contested by others or having what you're saying getting corrected. If you want to call what I've just spoken about as a "strawman", you can do you and I'll do me.

No, I'm not comfortable with what I've not said being contested, especially when i specifically said remote attack and someone overlooks the remote part and focuses on the attack part in order to make it appear to only be about semantics, in other words giving the impression that you were refuting my argument, while actually refuting an argument that was not presented by me.