AMD shares mitigation plans for Zen chipset security flaws

[DanceswithUnix]

AMD share price has dropped a bit recently, though I have to wonder if that is down to dropping bitcoin price more than this. Perhaps even the showy Nvidia raytracing demo (which AMD have made announcements but nothing as impressive). It would have been a nice time for their shares to actually go up a bit

[g8ina]

Test, TEST

[peterb]

That would be:



wouldn't it?

maybe - but not in a good way!

[CAT-THE-FIFTH]

Oh for sure, don't get me wrong I'm not saying all of reddit is like that, but when some people claim it's a Jewish plot or that because CTS-Labs is an Israeli based company it must be something to do with Intel it comes across as rather anti-Semitic and conspiratorial, occam's razor people.

Well the bloke who moaned about them being anti-Semitic then said this:

"or go buy a new processor without the design blunder" such as? AMD only? Crikey
I don't feel like giving more money to the saudis

So the irony. Regarding Intel,what do you expect after Intel did all the crap with Dell,AMD motherboards in unbranded boxes,etc - its no wonder all the theories are out.



If you look at those models,even Intel Z370 boards which have them - so one has to ask,why not make a bigger deal of the Intel side of things.

If it was from a safety point of view,there are probably far more Intel boards with the affect bits than AMD ones,as they have been shipping for years.

So their silence on the Intel side is really,really weird,as AT commented on:

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.

I had a quick look through the AdoredTV video,and he made a good point. Look at the offices of CTS-Labs,which someone managed to find a picture off on AT forums:

https://i.imgur.com/YT1Qfcs.jpg

Its the central one above the front door - its a tiny office it appears. Now,they mentioned in their interview with Toms Hardware,that they should have paid more researchers to look at their work(they said 5). They paid one chap's company $14000,so that means they easily had $70000 to $80000. Now look at the professional shot videos they did,the nice shiny website,and paying a marketing firm,etc.

They have money and as some pointed out,if they had followed normal disclosure procedures AMD would have paid them,or even taken on their services in the future,as would other companies. So despite this,they felt they were making more money,as pointed out even the stock shorting might not haved worked,as it didn't really affect AMD or Intel stock massively after Spectre/Meltdown was announced. So they have money,but where is the money coming from?

Viceroy research said they were sent the report hours before disclosure anonymously.

This comes to the last bit of the AT interview where David Kanter asked a few questions.

DK: I think the biggest question that I still have is that ultimately who originated this request for analysis – who was the customer that kicked this all off?

ILO: I definitely am not going to comment on our customers.

DK: What about the flavor of customer: is it a semiconductor company, is it someone in the industry, or is it someone outside the industry? I don’t expect you to disclose the name but the genre seems quite reasonable.

ILO: Guys I’m sorry we’re really going to need to jump off this call but feel free to follow up with any more questions.

So,they confirm that someone was basically involved in this. If not they would have said we ourselves started the work. They didn't.

Its why AMD said they wanted this investigated.

BTW,in case no one knows who David Kanter is:

https://www.realworldtech.com/
https://www.linkedin.com/in/kanterd

This is why Ian Cutress got him onboard.

[Ozaron]

So,they confirm that someone was basically involved in this. If not they would have said we ourselves started the work. They didn't.

Its why AMD said they wanted this investigated.

Even if AMD investigate themselves, is it a fair judgement to say we'll never actually know? I can't see the truth getting out, to be honest, whether CTS itself is sussed or not.

[CAT-THE-FIFTH]

Even if AMD investigate themselves, is it a fair judgement to say we'll never actually know? I can't see the truth getting out, to be honest, whether CTS itself is sussed or not.

Its all rather weird if they were looking at issues with ASMedia chips,why they seemingly "ignored" the bigger payout from Intel(far more Intel motherboards with them than AMD),but then we assume they did not go to Intel first anyway. Its such a weird decision,no wonder all the theories are popping up!! There is no real logic in how they approached this it appears.

[Corky34]

If you look at those models,even Intel Z370 boards which have them - so one has to ask,why not make a bigger deal of the Intel side of things.

It's difficult to know for sure what with the lack of technical details but from what i understand Intel isn't effected in the same manner because although the ASMedia ASICs are vulnerable they a) only handle USB3/3.1 on Intel platforms so an attack on that would only allow you to intercept data on that particular bus, b) the ASMedia ASIC on AMD systems handle much more than just USB, and c) the combination of the flaw in the ASMedia ASIC along with one or more vulnerabilities in the PSP is allowing the flashing of unsigned BIOS updates (something that AFAIK the Intel equivalent prevents).

[DanceswithUnix]

It's difficult to know for sure what with the lack of technical details but from what i understand Intel isn't effected in the same manner because although the ASMedia ASICs are vulnerable they a) only handle USB3/3.1 on Intel platforms so an attack on that would only allow you to intercept data on that particular bus, b) the ASMedia ASIC on AMD systems handle much more than just USB, and c) the combination of the flaw in the ASMedia ASIC along with one or more vulnerabilities in the PSP is allowing the flashing of unsigned BIOS updates (something that AFAIK the Intel equivalent prevents).

It's the same chip on the same PCIe bus standard. The problem here is that modern peripherals can transfer to and from any part of RAM they feel like. Remember, the AMD CPUs are really an SoC and most of what would be a chipset is already on the CPU. What they now call a chipset is just a PCIe I/O expander chip to turn 4 PCIe lanes into some more I/O.

The bit that is AMD specific in all this is the flaws in their ARM security CPU which is on board the main CPU *not* the "chipset" (which is of course optional in AM4). That's really embarrassing, and something that Intel have recently been through with them management processor. ISTR Intel had a remote exploit so AMD aren't quite as badly off here, but the general public won't see any distinction. I guess the person who thought getting a proper security audit done of that code wasn't worth the expense (probably something like $1M) is now regretting it.

[CAT-THE-FIFTH]

It's difficult to know for sure what with the lack of technical details but from what i understand Intel isn't effected in the same manner because although the ASMedia ASICs are vulnerable they a) only handle USB3/3.1 on Intel platforms so an attack on that would only allow you to intercept data on that particular bus, b) the ASMedia ASIC on AMD systems handle much more than just USB, and c) the combination of the flaw in the ASMedia ASIC along with one or more vulnerabilities in the PSP is allowing the flashing of unsigned BIOS updates (something that AFAIK the Intel equivalent prevents).

Ryzen is an SOC,and the ASMedia stuff is just a port expander,using PCI-E to expand the number of ports.

The fact is there is far more Intel systems out there,and this is what AT touched on:

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.

You also need to realise if you were writing malware,are you going to target an AMD CPU which barely has a few percent market penetration or millions of new and legacy Intel systems out there??

Also,Intel has had flaws in the IME too,yet there was nowhere as much coverage given to this in such a clickbait fashion by companies like CTS-Labs:

https://www.theregister.co.uk/2017/1...irmware_flaws/

Intel today admitted its Management Engine (ME), Server Platform Services (SPS), and Trusted Execution Engine (TXE) are vulnerable to multiple worrying security flaws, based on the findings of external security experts.

The firmware-level bugs allow logged-in administrators, and malicious or hijacked high-privilege processes, to run code beneath the operating system to spy on or meddle with the computer completely out of sight of other users and admins. The holes can also be exploited by network administrators, or people masquerading as admins, to remotely infect machines with spyware and invisible rootkits, potentially.

Meanwhile, logged-in users, or malicious or commandeered applications, can leverage the security weaknesses to extract confidential and protected information from the computer's memory, potentially giving miscreants sensitive data – such as passwords or cryptographic keys – to kick off other attacks. This is especially bad news on servers and other shared machines.

In short, a huge amount of Intel silicon is secretly running code that is buggy and exploitable by attackers and malware to fully and silently compromise computers. The processor chipsets affected by the flaws are as follows:

6th, 7th and 8th Generation Intel Core processors
Intel Xeon E3-1200 v5 and v6 processors
Intel Xeon Scalable processors
Intel Xeon W processors
Intel Atom C3000 processors
Apollo Lake Intel Atom E3900 series
Apollo Lake Intel Pentiums
Celeron N and J series processors

Intel's Management Engine, at the heart of today's disclosures, is a computer within your computer. It is Chipzilla's much maligned coprocessor at the center of its vPro suite of features, and it is present in various chip families. It has been assailed as a "backdoor" – a term Intel emphatically rejects – and it is a mechanism targeted by researchers at UK-based Positive Technologies, who are set to reveal in detail new ways to exploit the ME next month.

The Management Engine is a barely documented black box. It has its own CPU and its own operating system – recently, an x86 Quark core and MINIX – that has complete control over the machine, and it functions below and out of sight of the installed operating system and any hypervisors or antivirus tools present.

It is designed to allow network administrators to remotely or locally log into a server or workstation, and fix up any errors, reinstall the OS, take over the desktop, and so on, which is handy if the box is so messed up it can't even boot properly.

The ME runs closed-source remote-administration software to do this, and this code contains bugs – like all programs – except these bugs allow hackers to wield incredible power over a machine. The ME can be potentially abused to install rootkits and other forms of spyware that silently snoop on users, steal information, or tamper with files.

SPS is based on ME, and allows you to remotely configure Intel-powered servers over the network. TXE is Intel's hardware authenticity technology. Previously, the AMT suite of tools, again running on ME, could be bypassed with an empty credential string.

Today, Intel has gone public with more issues in its firmware. It revealed it "has identified several security vulnerabilities that could potentially place impacted platforms at risk" following an audit of its internal source code:

In response to issues identified by external researchers, Intel has performed an in-depth comprehensive security review of our Intel Management Engine (ME), Intel Server Platform Services (SPS), and Intel Trusted Execution Engine (TXE) with the objective of enhancing firmware resilience.

The flaws, according to Intel, could allow an attacker to impersonate the ME, SPS or TXE mechanisms, thereby invalidating local security features; "load and execute arbitrary code outside the visibility of the user and operating system"; and crash affected systems. The severity of the vulnerabilities is mitigated by the fact that most of them require local access, either as an administrator or less privileged user; the rest require you to access the management features as an authenticated sysadmin.
Intel 5th Generation Core processor with vPro
Intel ME controller chip has secret kill switch
READ MORE

But as Google security researcher Matthew Garrett pointed out in the past hour or so, the aforementioned AMT flaw, if not patched, could allow remote exploitation.

In other words, if a server or other system with the AMT hole hasn't been updated to kill off that vulnerabilities, these newly disclosed holes will allow anyone on the network to potentially log in and execute malicious code within the powerful ME coprocessor.

"The ME compromise presumably gives you everything the AMT compromise gives you, plus more," said Garrett via Twitter. "If you compromise the ME kernel, you compromise everything on the ME. That includes AMT, but it also includes PTT."

He explained, "PTT is Intel's 'Run a TPM in software on the ME' feature. If you're using PTT and someone compromises your ME, the TPM is no longer trustworthy. That probably means your Bitlocker keys are compromised, but it also means all your remote attestation credentials are toast."

Garrett said if an exploit allows unsigned data to be installed and interpreted by the ME, an attacker could effectively trigger the reinfection of malware after every ME reboot. Were that to happen, the only way to fix things would be to reflash the hardware by hand. At that point, he said, it would probably be cheaper just to get new hardware.

Intel said systems using ME Firmware versions 11.0, 11.5, 11.6, 11.7, 11.10, and 11.20, SPS Firmware version 4.0, and TXE version 3.0 are affected. The cited CVE-assigned bugs are as follows:

Intel Manageability Engine Firmware 11.0.x.x/11.5.x.x/11.6.x.x/11.7.x.x/11.10.x.x/11.20.x.x
CVE-2017-5705: "Multiple buffer overflows in kernel in Intel Manageability Engine Firmware 11.0/11.5/11.6/11.7/11.10/11.20 allow attacker with local access to the system to execute arbitrary code." Logged-in superusers, or high-privilege programs, can execute code within the hidden Management Engine, below the OS and any other software.
CVE-2017-5708: "Multiple privilege escalations in kernel in Intel Manageability Engine Firmware 11.0/11.5/11.6/11.7/11.10/11.20 allow unauthorized process to access privileged content via unspecified vector." Logged-in users or running apps can slurp confidential information out of memory. This is very bad news on a shared system.
CVE-2017-5711: "Multiple buffer overflows in Active Management Technology (AMT) in Intel Manageability Engine Firmware 8.x/9.x/10.x/11.0/11.5/11.6/11.7/11.10/11.20 allow attacker with local access to the system to execute arbitrary code with AMT execution privilege." Logged-in superusers, or high-privilege programs, can execute code within the AMT suite, below the OS and any other software.
CVE-2017-5712: "Buffer overflow in Active Management Technology (AMT) in Intel Manageability Engine Firmware 8.x/9.x/10.x/11.0/11.5/11.6/11.7/11.10/11.20 allows attacker with remote Admin access to the system to execute arbitrary code with AMT execution privilege." People with network access to a machine, and can log in as an admin, can execute code within the AMT suite.
Intel Manageability Engine Firmware 8.x/9.x/10.x
CVE-2017-5711: "Multiple buffer overflows in Active Management Technology (AMT) in Intel Manageability Engine Firmware 8.x/9.x/10.x/11.0/11.5/11.6/11.7/11.10/11.20 allow attacker with local access to the system to execute arbitrary code with AMT execution privilege." Logged-in superusers, or high-privilege programs, can execute code within the AMT suite, below the OS and any other software.
CVE-2017-5712: "Buffer overflow in Active Management Technology (AMT) in Intel Manageability Engine Firmware 8.x/9.x/10.x/11.0/11.5/11.6/11.7/11.10/11.20 allows attacker with remote Admin access to the system to execute arbitrary code with AMT execution privilege." People with network access to a machine, and can log in as an admin, can execute code within the AMT suite.
Server Platform Service 4.0.x.x
CVE-2017-5706: "Multiple buffer overflows in kernel in Intel Server Platform Services Firmware 4.0 allow attacker with local access to the system to execute arbitrary code." Logged-in superusers, or high-privilege programs, can execute code within the hidden Management Engine, below the OS and any other software.
CVE-2017-5709: "Multiple privilege escalations in kernel in Intel Server Platform Services Firmware 4.0 allows unauthorized process to access privileged content via unspecified vector." Logged-in users or running apps can slurp confidential information out of memory. This is very bad news on a shared system.
Intel Trusted Execution Engine 3.0.x.x
CVE-2017-5707: "Multiple buffer overflows in kernel in Intel Trusted Execution Engine Firmware 3.0 allow attacker with local access to the system to execute arbitrary code." Logged-in superusers, or high-privilege programs, can execute code within the hidden Management Engine, below the OS and any other software.
CVE-2017-5710: "Multiple privilege escalations in kernel in Intel Trusted Execution Engine Firmware 3.0 allows unauthorized process to access privileged content via unspecified vector." Logged-in users or running apps can slurp confidential information out of memory. This is very bad news on a shared system.

Chipzilla thanked Mark Ermolov and Maxim Goryachy at Positive for discovering and bringing to its attention the flaw CVE-2017-5705, which sparked the aforementioned review of its source code for vulnerabilities.

Intel advises Microsoft and Linux users to download and run the Intel-SA-00086 detection tool to determine whether their systems are vulnerable to the above bugs. If you are at risk, you must obtain and install firmware updates from your computer's manufacturer, if and when they become available. The new code was developed by Intel, but it needs to be cryptographically signed by individual hardware vendors in order for it to be accepted and installed by the engine.

Lenovo was quick off the mark with patches for its gear ready to download.

We'll give you a roundup of fixes as soon as we can. It's not thought Apple x86 machines are affected as they do not ship with Intel's ME, as far as we can tell.

Today's news will no doubt fuel demands for Intel to ship components free of its Management Engine – or provide a way to fully disable it – so people can use their PCs without worrying about security bugs on mysterious secluded coprocessors. ®

So why didn't CTS-Labs make an Intelflaws.com too?? Seems rather weird and the IME issues was with multiple generations of CPUs including Atom based ones.

[Corky34]

It's the same chip on the same PCIe bus standard.
<Snip>

Yes i know it's the same chip but like i said the flaw in that chip (afaik) would only allow you exploit that single chip on an Intel system as the equivalent of PSP (i forget what Intel call it) would either a) block an attempt to flash that chip with unsigned firmware, or b) prevent the compromised chip from effecting anything outside of what it's responsible for (USB3/3.1 in Intel's case).

AMD's PSP should be doing the same prevention of installing unsigned firmware/drivers but from what i can tell these exploits circumvent that, that's the whole reason AMD and Intel include these security processors, they're meant to prevent someone installing unsigned firmware/software/drivers, AKA rootkits, and somehow these exploits have circumvented those protections.

Also,Intel has had flaws in the IME too,yet there was nowhere as much coverage given to this in such a clickbait fashion by companies like CTS-Labs:

They key word there is "had", from what i can tell these exploits aren't much different in terms of practicalities as those that used to exist in Intel's security related protections.

So why didn't CTS-Labs make an Intelflaws.com too?? Seems rather weird and the IME issues was with multiple generations of CPUs including Atom based ones.

Because (afaik) they've been fixed.

[CAT-THE-FIFTH]

They key word there is "had", from what i can tell these exploits aren't much different in terms of practicalities as those that used to exist in Intel's security related protections.

The key words are that the researchers who found it told Intel weeks or months before and they patched it before the world was told. Intel was given at least a degree of warning to fix it.

The key words are that CTS-Labs said these issues could take years to fix. Utter nonsense.

The key words are they never explained why they gave only 24 hours notice to AMD and the key words are WHY they told the press before AMD.

The key words are why they are on purpose ignoring the tens of millions of Intel motherboards which might have the same issues. They themselves said they were looking at ASMedia chips and these are in multiple vendors systems.

The key words are why they made a clickbait trolling website called "AMDFLAWS" when they didn't do the tests on Intel systems and make an "INTELFLAWS" website.

So,one has to ask if Intel was given 24 hours and the press were told before them,would the vulnerabilities be unpatched?? Oh,wait!!

They made it into a bigger issue than it is in reality especially as IME has tons of issues reported over the last year and researchers have given a company like Intel with 106000 employees LOADs of time to sort it out.

Plus I trust the word of David Kanter,etc who pretty much called them out:

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.

The fact of the matter is Ryzen is only a very small percentage of all current AMD systems,so any potential ASMedia chip flaws on Intel systems are automatically FAR WORSE as they are on a larger number of deployed systems including many governmental ones. If you want to write malware,Intel would be the bigger target.

People trying to not consider the issue on Intel are not really making any sense. If anything CTS-Labs are not transparent:

DK: I think the biggest question that I still have is that ultimately who originated this request for analysis – who was the customer that kicked this all off?

ILO: I definitely am not going to comment on our customers.

DK: What about the flavor of customer: is it a semiconductor company, is it someone in the industry, or is it someone outside the industry? I don’t expect you to disclose the name but the genre seems quite reasonable.

ILO: Guys I’m sorry we’re really going to need to jump off this call but feel free to follow up with any more questions.

The whole thing is not transparent which is what security firms should ideally be.

Because (afaik) they've been fixed but I am trying to forget the fact Intel was given weeks if not months of notice to fix the problems and didn't have a clickbait firm telling the media before Intel of any issues and a clickbait IntelFLAWS website.

FTFY.

So you are saying 100% that none of the ASMedia chips on Intel platforms have an issue? Links please.

Were they given under 24 hours notice??

[CAT-THE-FIFTH]

To show you the despicable way CTS-Labs did stuff,lets look at how Positive,handled the Intel issues:

https://www.theregister.co.uk/2017/1...irmware_flaws/

Chipzilla thanked Mark Ermolov and Maxim Goryachy at Positive for discovering and bringing to its attention the flaw CVE-2017-5705, which sparked the aforementioned review of its source code for vulnerabilities.

Intel advises Microsoft and Linux users to download and run the Intel-SA-00086 detection tool to determine whether their systems are vulnerable to the above bugs. If you are at risk, you must obtain and install firmware updates from your computer's manufacturer, if and when they become available. The new code was developed by Intel, but it needs to be cryptographically signed by individual hardware vendors in order for it to be accepted and installed by the engine.

Lenovo was quick off the mark with patches for its gear ready to download.

So,Intel and its partners had enough time for the patches to be deployed.

AMD is ambushed by CTS-Labs and it seems this is trying to be considered "normal".It isn't.

The company only revealed AFTER Intel had been told and made mitigations,on how it acted.

Intel's Management Engine, at the heart of today's disclosures, is a computer within your computer. It is Chipzilla's much maligned coprocessor at the center of its vPro suite of features, and it is present in various chip families. It has been assailed as a "backdoor" – a term Intel emphatically rejects –and it is a mechanism targeted by researchers at UK-based Positive Technologies, who are set to reveal in detail new ways to exploit the ME next month.

So Positive has given Intel prior warning,yet CTS-Labs didn't.

Here is yet ANOTHER issue discovered LAST year:

https://www.theregister.co.uk/2017/0...emote_exploit/

Code dive You can remotely commandeer and control computers that use vulnerable Intel chipsets by sending them empty authentication strings.

Thus, AMT is designed to allow IT admins to remotely log into the guts of computers so they can reboot a knackered machine, repair and tweak the operating system, install a new OS, access a virtual serial console, or gain full-blown remote desktop access via VNC. It is, essentially, god mode.

Thanks go to Embedi, which reverse engineered the code [PDF] and also reported the flaw to Intel back in March. Tenable also poked around in the service and came to the same conclusion earlier this week.

Intel has published some more info on the vulnerability here, which includes links to a tool to check if your system is at-risk, support contact details, and a list of mitigations to reduce the threat. That tool is apparently Windows-only; there's info here for Linux peeps.

There is also this third-party tool, here, for disabling AMT from Windows.

So see last year when Intel had another issue,the researcher reported it to them in March. Intel told the world in May when they released the fix.

CTS-Labs knew very well if they told AMD about this with two to three months notice,they would have most likely fixed the issue,and be done with it.

Instead they made sure they blindsided AMD on purpose for maximum clickbait effect so to make sure AMD had no chance to reasonably respond.

Yet they seem utterly fearful of doing it to Intel,since Intel has so much sway in the industry if they tried that crap,they would be probably be finished.

Its easy to see why - AMD is small fry so can't push back against dodgy practices. Intel and Nvidia are larger in their respective specialities(and have more money),and if you try to screw them over,they will more often than not push back since they can afford to.

To put it in context,Intel employs MORE people in Israel ALONE(over 10000),than AMD has people to cover CPUs and dGPUs(around 9000) at all its sites globally. AMD is utterly tiny in comparison.

So a small company like AMD,is given NO warning yet a company with 106000 people is given time - this is like a REVERSE Robin Hood.

Its to be expected from a company which made malware like CrowdCores,and then rebranded their own website to hide the fact.

[DanceswithUnix]

Instead they made sure they blindsided AMD on purpose for maximum clickbait effect so to make sure AMD had no chance to reasonably respond.

I particularly liked the way they boldly claimed some of it couldn't be fixed.

They key word there is "had", from what i can tell these exploits aren't much different in terms of practicalities as those that used to exist in Intel's security related protections.

Oh Intel's IME used to leak like a sieve and was like that for years apparently with Intel not caring a jot about it. Surprised it took as long as it did to blow up in their face frankly, Charlie over at SemiAccurate was on their case for ages.

[CAT-THE-FIFTH]

I particularly liked the way they boldly claimed some of it couldn't be fixed.

Yep. I mean I could even understand if they had given AMD like 3+ months,and they didn't do anything,but the whole way they approached this is utterly weird. I mean I have had a go at AMD myself,for certain stupid things they have done,but this is just literally taking the micky,since AMD must have been like REALLY??

Security researchers if they are truely doing it for the public good should be working with companies,not doing the opposite.

I mean the fact that at the end of the interview with AT,they inadvertently said someone funded this "study" so one has to ask,who??

They basically implemented themselves. Now they won't answer any additional questions AT sent to them. That sounds like there is something they want to hide.

[Corky34]

<Some sort of typical Cat rant>

I'm not going to read that as it's obvious you've either misunderstood what i waqs saying or you're just got up on the wrong side of bad today and are looking for someone to argue with.

I case you missed it I'm not excusing how, what, when or anything else about the way CTS-Labs dealt with things, I'm simply stating what i believe the vulnerabilities, why and how they work, and why they don't effect Intel despite them sharing the same ASMedia ASICs.

Lest you've forgotten AMD themselves have confirmed these vulnerabilities exist, if you could move past how you feel about CTS-Labs perhaps we could have a constructive discussion about the actual vulnerabilities instead of how you and i feel about how the disclosure was handled.

[scaryjim]

... why they don't effect Intel despite them sharing the same ASMedia ASICs. ...

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.

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?