AMD's Future Chips & SoC's: News, Info & Rumours.

[goldstone77]

Would ya stop same is true for Intel machines 10 million Intel MB use an AsMedia chip (also true for ones that don't use asmedia chips)...

No. As explained before the the Intel mobos that use ASMedia chipset use it as USB controller, not as a security processor with access to everything. The flaw only exists on AMD systems. Reason why it is named AMDflaws.

You mixed me up with Jaymc for that quote. But my motherboard, and a few others I have, are Asus motherboards that use ASMedia for PCI-E controllers. They are Intel motherboards.

Corrected attribution to jaymc.

I already explained here

http://www.tomshardware.co.uk/forum/id-3341285/amd-naples-server-cpu-info-rumours/page-31.html#20799427

that AMD flaws don't affect to Intel mobos that use ASMedia chipsets for USB or PCie controllers. The problem is only on AMD Zen hardware because AMD uses those ASMedia chips as part of the Zen-platform Secure Processor with access to everything.

AMD And CTS Labs: A Story Of Failed Stock Manipulation
Mar. 16, 2018 3:59 PM ET

Ryzenfall

Similarly Ryzenfall targets AMD's Secure OS, the OS that's running on the ARM Cortex A5 secure processor. It requires the attacker to have access to the system, administrator or root privileges, and a copy of a signed driver with the exploit code inside the driver.

According to CTS' white paper:

"Although Secure OS runs inside the Secure Processor’s dedicated ARM Cortex A5 processor, it does make use of the computer’s main memory. When Secure OS starts, it allocates a portion of main memory for its own use and seals it off from the main processor. This area is called Fenced DRAM."

The vulnerability allows access to this "Fenced DRAM" which is generally supposed to be inaccessible to kernel drivers and user programs. This is, in my opinion, a more serious vulnerability. Though actually executing this vulnerability in the wild would entail finding a friendly OEM willing to sign your malicious code and include it in their drivers, this is not entirely outside the scope of possibility.

That said, it is important to note that even the CTS' white paper mentions that AMD has already included a BIOS option to disable the Secure OS feature, as it's not necessary for regular server or desktop operation. Further, since the ONLY shred of proof was provided in the Masterkey section, it's not entirely clear if it's even real. To avoid repeating myself, the same goes for Fallout and Chimera.

https://seekingalpha.com/article/4157242-amd-cts-labs-story-failed-stock-manipulation?auth_param=1e5lib:1dao8gu:9d1ed7dd5479b8f7dbd2b10a2ceecaa3&dr=1

 

[RealBeast]

CTS Labs Speaks: Why It Blindsided AMD With Ryzenfall And Other Vulnerabilities

http://www.tomshardware.com/news/cts-labs-amd-ryzenfall-ryzen-epyc,36660.html

Nice smackdown from Linus: https://www.realworldtech.com/forum/?threadid=175139&curpostid=175168 :lol:

 

[jaymc]

AMD And CTS Labs: A Story Of Failed Stock Manipulation:

https://seekingalpha.com/article/4157242-amd-cts-labs-story-failed-stock-manipulation?page=4

 

[jaymc]

All of these issues require admin/root user access to exploit, which on any system, Intel included, would be compromised and anyone would have free reign of your system anyway! Example: leaving your laptop in a public place with a sticky note attached displaying admin login password.
It doesn't matter that there is a payload with AMD's name on it.

Of course, anyone with administrative login credentials cold enter any Intel/AMD syustem and steal info or install backdorrs. This is not the problem that is being reported, because the backdoors in your Intel laptop can be detected and easily eliminated with standard techniques. Unlike what happens with attacks exploiting AMDflaws.

On AMD-Zen system the backdoors are persistent and virtually undetectable. So someone can be accessing your laptop or your server and you almost unable to detect it, and in case you detect some backdoor installed in your AMD system, persistence implies it cannot be eliminated from the system. As experts mention the only mitigation would be to replace your laptop or your server by one new.

Would ya stop same is true for Intel machines 10 million Intel MB use an AsMedia chip (also true for ones that don't use asmedia chips)...

No. As explained before the the Intel mobos that use ASMedia chipset use it as USB controller, not as a security processor with access to everything. The flaw only exists on AMD systems. Reason why it is named AMDflaws.

I'm not gonna get sucked into an argument with you Juan as I cannot reason with you so it's a waste of time.

 

[ex_bubblehead]

I will only say this once. Knock off the petty bickering immediately or there will be some ejections.

The only acceptable response here is "I understand the warning" Anything else will result in some time off for the offender/s.

 

[jaymc]

AMD Ryzen 2nd Generation may launch on April 19:

https://www.techradar.com/news/amd-ryzen-2nd-generation-may-launch-on-april-19

 

[juanrga]

CTS Labs Speaks: Why It Blindsided AMD With Ryzenfall And Other Vulnerabilities

http://www.tomshardware.com/news/cts-labs-amd-ryzenfall-ryzen-epyc,36660.html

Nice smackdown from Linus: https://www.realworldtech.com/forum/?threadid=175139&curpostid=175168 :lol:

Don't miss the reply to him 😉

https://www.realworldtech.com/forum/?threadid=175139&curpostid=175180

 

[-Fran-]

CTS Labs Speaks: Why It Blindsided AMD With Ryzenfall And Other Vulnerabilities

http://www.tomshardware.com/news/cts-labs-amd-ryzenfall-ryzen-epyc,36660.html

Nice smackdown from Linus: https://www.realworldtech.com/forum/?threadid=175139&curpostid=175168 :lol:

Don't miss the reply to him 😉

https://www.realworldtech.com/forum/?threadid=175139&curpostid=175180

Am I playing this correctly?

https://www.realworldtech.com/forum/?threadid=175139&curpostid=175185

Cheers!

 

[juanrga]

CTS Labs Speaks: Why It Blindsided AMD With Ryzenfall And Other Vulnerabilities

http://www.tomshardware.com/news/cts-labs-amd-ryzenfall-ryzen-epyc,36660.html

Nice smackdown from Linus: https://www.realworldtech.com/forum/?threadid=175139&curpostid=175168 :lol:

Don't miss the reply to him 😉

https://www.realworldtech.com/forum/?threadid=175139&curpostid=175180

Am I playing this correctly?

https://www.realworldtech.com/forum/?threadid=175139&curpostid=175185

He is wrong

https://www.realworldtech.com/forum/?threadid=175139&curpostid=175191

 

[juanrga]

The truth starts to arise slowly...

As the dust settled after yesterday's overly-cosmeticized vulnerability disclosure, many security researchers are now not so dismissive of CTS Labs' findings, and the conspiracy theories about shorting AMD stock are starting to be replaced by warnings that the AMD flaws "could turn bad hacks into worse hacks."

This was because experts started realizing that attackers could use these AMD vulnerabilities to gain post-reinstall persistence by leaving malicious code in secure areas of the CPU. Areas where security software can't scan or reach, and where malicious attackers wouldn't normally be able to reach, admin access or not.

https://www.bleepingcomputer.com/news/security/researchers-who-found-amd-cpu-flaws-explain-chaotic-disclosure/

 

[-Fran-]

Since day one everyone has known about the "bad hacks turning into worse hacks". All of the mocking that CTS has been getting is about their lack of professional touch with the information and, obviously, timing.

There's an official investigation being assembled at the moment (I can't remember where I read it, sorry) to check if there was any stock market manipulation intentions over this.

Like I said already, the findings might as well be true and problematic for AMD, but they've lost face hard. I'll side with Linus on this, although I disagree just a bit: these should be treated as bugs and not as end-of-the-world problems. AMD needs or might not even need to patch them, but there are 2 sides to this whole CTS story that have a lot of weight on their own: disclosure and evidence.

No need to continue with this debate of whether or not their findings have merit, because the discussion has always been "yeah, but it's stupid anyway". AMD needs to issue an official response on what the next steps are and we should just sit and wait until then.

Cheers!

 

[jaymc]

Agreed... AMD have been too quiet. They need to do a better job of getting ahead of FUD like this.. an there's probably more on the way don't ya know this will not be the last spanner that gets thrown in their works.

I like this part "The security vulnerability here is that your root is compromised."

Also I was wondering if someone contracted a team of code jockeys for nine months or so, to mod Intel's BIOS's an write exploits for their CPU's, what the results would look like. I think AMD came out pretty well considering the effort that was obviously put in.

 

[juanrga]

Since day one everyone has known about the "bad hacks turning into worse hacks". All of the mocking that CTS has been getting is about their lack of professional touch with the information and, obviously, timing.

No problem with people criticizing CTS-labs [absence of] professionalism, or with their non-standard disclosure method, or whatever you want.

The problem is on that people and media are focusing only on criticizing CTS-labs, whereas ignoring the security flaws. People as Linus that pretends that CTS-labs is a scam, despite the flaws have been confirmed by security experts outside CTS-labs. Alex Lionescu has denounced this media distraction:

On the #AMDflaws — I have seen the technical details and there are legit design & implementation issues worth discussing as part of a coordinated disclosure effort. The media storm and handling around that is sadly distracting from a real conversation around security boundaries.

 

[-Fran-]

Since day one everyone has known about the "bad hacks turning into worse hacks". All of the mocking that CTS has been getting is about their lack of professional touch with the information and, obviously, timing.

No problem with people criticizing CTS-labs [absence of] professionalism, or with their non-standard disclosure method, or whatever you want.

The problem is on that people and media are focusing only on criticizing CTS-labs, whereas ignoring the security flaws. People as Linus that pretends that CTS-labs is a scam, despite the flaws have been confirmed by security experts outside CTS-labs. Alex Lionescu has denounced this media distraction:

On the #AMDflaws — I have seen the technical details and there are legit design & implementation issues worth discussing as part of a coordinated disclosure effort. The media storm and handling around that is sadly distracting from a real conversation around security boundaries.

And that is what I said was answered on day 1. Linus has been vocal on mocking them (as his usual self) due to the way they presented the paper. I can't speak for him, obviously, but I'm pretty damn sure he's not dissing the issues themselves, but the company that presented the evidence.

In any case; it doesn't matter what we think of the issues (including external "security experts"). AMD has to get a statement out saying if the findings are dumb or not; if they really have merit or not. They're the only company that can really put the nail on this discussion since they are the real owners of the design and implementation.

We could make bets on what they'll say though. My bet is they'll patch this with new hardware, but downgrade the findings due to the complexity of achieving the breach.

Cheers!

 

[juanrga]

AMD And CTS Labs: A Story Of Failed Stock Manipulation:

https://seekingalpha.com/article/4157242-amd-cts-labs-story-failed-stock-manipulation?page=4

Kinda ironic that a guy that owns AMD stock writes a biased article about stock manipulation.

To back up this claim, it has had its findings reviewed by not less than ONE, yes, just one, company, Trail of Bits.

The findings have been reviewed and confirmed by more than one.

To further bolster its claim, it has produced one, yes, just one, screenshot of one affected machine where the boot code in the bottom left coroner was replaced with the number "1337."

That is in the public material. The material sent to security experts and to AMD contains working PoCs for all the vulnerabilities on all the hardware.

These findings caused Viceroy Research, another firm with a questionable reputation, to proclaim in a 25-page report on the matter that: "AMD must cease the sale of Ryzen and EPYC chips in the interest of public safety."

I am not defending Viceroy tactics/wording, but the above quote form the Viceroy report is related to this:

AMD’s flawed chips are components in government and defense products –AMD is pushing Embedded Ryzen and EPYC chips into government and defense industries– from aerospace through to enterprise servers and laptops –through promotion of “advanced security” of its Secure Processor– the very Secure Processor which CTS has found to be fundamentally flawed and open to hacking

It is totally legit to criticize Viceroy by their tactics/wording, but full quotes and context would be given as part of genuine criticism.

By contrast CTS's white paper, which can be found on amdflaws.com, and yet inexplicably hosted by a blank website safefirmware.com, discusses no methodology at all, and for proof of concepts discussed therein offers just one screenshot of a server with a boot screen with "1337" (hacker slang for LEET which is phonetic shortening of ELITE) added to the bottom right hand corner, purportedly by CTS. Due to the lack of any discussion of methodology or technical details in the white paper, it is impossible to verify the veracity of CTS's claims. That said, let's discuss them at face value anyway and see what the worst-case scenario could be.

CTS-labs explained why the paper is hosted on safefirmware. The public whitepaper lacks technical details. The private whitepaper contains the full details. CTS-labs explained that they eliminated the relevant details from the pubic material: "We did not publish technical details about the flaws, to avoid putting users at risk. Right now the public is aware of the vulnerabilities, AMD has been provided full details and are now working on patches, and security vendors have also been given full details and are now developing mitigations."

The SA author also forget to mention that the CTS claims have been verified by security experts outside CTS-labs.

However, in order to deploy this vulnerability [MASTERKEY], the attacker would have to first get access to the computer, then gain root or administrator privileges, and then finally have the ability to flash (update) the BIOS on the computer.

"RYZENFALL, FALLOUT and CHIMERA do not require physical access to exploit. MASTERKEY requires BIOS re-flashing, but that is often possible by just having local admin on the machine and running an EXE. We've confirmed this works on motherboards by Tyan, ASUS, ASRock, Gigabyte, Biostar, and others."

Further, since the ONLY shred of proof was provided in the Masterkey section, it's not entirely clear if it's even real. To avoid repeating myself, the same goes for Fallout and Chimera.

Working PoCs for all the attacks have been provided in the non-public material and that they work on AMD hardware confirmed by people outside CTS-labs.

https://twitter.com/dguido/status/973628933034991616

Fallout uses the same attack vector of a signed driver as Ryzenfall, but on an EPYC processor by targeting the boot loader, with identical results, and identical dubiousness of the proof of concept.

Idem above. So since they have working code for this vulnerability, one would ask how CTS-labs got a working driver for the attack. They also answer this: "Any signed driver that provides access to IO spaces is sufficient to interact with the backdoors. There is a vendor-supplied driver that does this". CTS-labs also confirmed the needed driver is "publicly available for download?".

Chimera is the most serious sounding "vulnerability." [...] CTS bases this bold supposition NOT on actual testing, or proof of concept, but on the fact that it claimed to have reviewed the code from AMD's subcontractor, ASMedia, and AMD's chipset code and found similarities between the two code bases. ASMedia reused some of its own code while fulfilling a contract for AMD. What a shock?

Another false. Once again. Working PoCs there exist for all the flaws.

Even Dan Guido, the CEO of Trail of Bits, the one and only company hired by CTS to double check its findings, disputes the validity of Chimera in a tweet to reporters.

False again. He has confirmed at least three times that Chimera is real, including this "The CHIMERA vulnerability abuses exposed interfaces of the AMD Promontory chipset to gain code execution in the chipset processor."

Further, ExtremeTech published an article where it shows that the same ASMedia chips accused of housing backdoors by CTS also are widely used on any ASUS motherboards with Intel chips. So, why is this categorized as an AMD flaw when it widely affects, if real, both AMD and Intel?

Joel's article was refuted in the comments section of ExtremeTech. CTS-labs categorized CHIMERA as AMD flaw because the failure is in the promontory chipset from AMD. Intel doesn't have a similar chipset, so there is no Intelflaw. Said this, some mobos for Intel systems use the affected ASMedia chips as USB controller. Those mobos could be vulnerable to chimera-like attacks, but the failure here is on ASMedia or in the motherboard company. It could be named Asusflaw if some Asus mobos are affected but not Intelflaw, because it is not flaw from Intel.

Moreover, CTS-labs checked this on Intel hardware: "We've looked into quite a few computers made by HP, Dell, Lenovo, etc. and they were not affected."

If Fallout and Ryzenfall are indeed real, hopefully AMD will patch them quickly, as those threaten AMD's Secure Encrypted Virtualization system. Chimera just looks like nonsense, unless further proof is provided, and Masterkey requires a BIOS flash. If you can flash the BIOS all bets are off, on ALL systems, from ALL CPU vendors.

All the flaws are real. CTS-labs and consulted external experts shared doubts about the flaws can be patched quickly by AMD. And BIOS re-flashing is possible by simply running an EXE: "We've confirmed this works on motherboards by Tyan, ASUS, ASRock, Gigabyte, Biostar, and others."

Potential technical impact of AMDFlaws

* Code execution in the PSP and SMM (no visibility to typical security products)
* Persistence across OS reinstallation and BIOS updates
* Block or infect further BIOS updates, or brick the device
* Bypass Windows Credential Guard
* Bypass Secure Encrypted Virtualization (SEV)
* Bypass Secure Boot
* Bypass or attack security features implemented on top of the PSP (e.g., fTPM)

Rather than giving AMD a standard 90-day advance notice adopted by Google, Cisco (NASDAQ:CSCO) and others, or the 200-day-plus notice Google gave Intel, AMD, and others before disclosing Meltdown and Spectre, CTS gave AMD less than a day advance notice.

CTS-labs explained why they don't like the standard disclosure method and advocate for their method.

All the subsequent discussion in the article about green screens, domain creations, or Viceroy tactics/wording ... is simply smoke to divert the attention apart from the security flaws

https://twitter.com/aionescu/status/974028647307849730

Finally, It is interesting that the author of the SA article "discuss the credibility, or rather the lack thereof, of CTS Labs", when his own credibility as financial consultant doesn't look very good with a ranking of only 1/2 over 5

 

[juanrga]

Very interesting discussion happening between David Schor and other people. The so-claimed reduction of cache latency to 12 cycles in Raven Ridge and Pinnacle Ridge is not true. Zen always had 12 cycles latency as confirmed by AMD internal reports and reviews of EPYC.

https://twitter.com/david_schor/status/975609547938304001

 

[juanrga]

Specs for the 2600X confirmed by Amazon

 

[Gon Freecss]

4.2GHz I think is going to be the new 4GHz.

Funny thing that a mature 14nm or "12nm" process will overclock on par or worse than Broadwell.

 

[8350rocks]

Spoiler

So, they are open to auditing your "competitor's product!" For a small fee I'm sure 😉!

What? They are paid for security checking work? This is a scandal!

ASMedia is also used in all of Intel's USB 3.0 host controllers and hubs.

There are two kind of attacks reported: those based in ASMedia chipsets and those exclusive to AMD hardware/software. And for the former kind, having a ASMedia chipset is a needed but not enough requirement, because the chipsets can be implemented in a platform with workarounds to mitigate the flaws on the chipsets.

There is also a fundamental difference between AMD Zen systems and Intel boards with the ASMedia chipsets, as someone else wrote in another part:

Intel boards don't have the same problems because they use the ASM1142 as a USB controller, not their Security Processor.

For the ASM1142, a USB and PCI interface is added on and you have a USB interface chip. I'm currently working on an ST Micro design that uses an ARM cell as the basis for a USB to serial converter. They use that same ARM cell in the Bluetooth controller attached to the converter. They just add different peripherals to the ARM, more memory, Bluetooth hardware, and encryption hardware for the Bluetooth protocol, etc.

Now what I'm suspecting AMD did was take an ASMedia ARM cell and build their Security Processor around it by adding an encryption engine and other peripherals. But it's that same ARM cell in the middle. And that is where the problem lies. AMD may have left the debug port on the cell open.

Go ahead and read all the articles on the problem again. My theory is consistent with everything that I've been able to find. And is it consistent with CTS finding the problem on Intel boards and AMD. The problem is with the ARM cell, likely the debug port. Its just that on Intel, it's just a USB controller. On AMD, it's the Security Processor with access to everything.

So this is AMD flaw, not Intel flaw, neither ASMedia flaw.

You left off the relevant part...these "hacks" all require local (i.e. physical) access to the machine, and require admin rights on the machine in question.

If someone has physical access with admin rights, and wants to do something malicious...they need not attempt these "hacks" they can just literally do whatever they want.

Which is why no one is concerned about this "flaw", and why no one is taking it seriously. If someone has physical access with admin permissions on any machine, regardless of processor type, that machine is compromised.

To quote one security executive:

This is the equivalent of giving someone the keys to your home, and allowing them to do as they like...only now they have put in cameras in obvious places while they are there.

Additionally...the BIOS hack requires a signed BIOS update...which means someone would have to somehow replicate a board vendors authentication. Which is unlikely to even be plausible.

Not to mention there are no proof of concepts, no code examples, and no information.

Lastly, when David Kanter and Ian Cuttress interviewed the CTS Labs "security experts", the CTS Labs guys cut the call short because they could not answer the last half of the questions, and it was only becoming painfully obvious they were completely incompetent. Which makes it look even more like a hit piece put forth to try to impact stock prices.

 

[-Fran-]

Very interesting discussion happening between David Schor and other people. The so-claimed reduction of cache latency to 12 cycles in Raven Ridge and Pinnacle Ridge is not true. Zen always had 12 cycles latency as confirmed by AMD internal reports and reviews of EPYC.

https://twitter.com/david_schor/status/975609547938304001

There's an overall reduction of latency, so I would imagine the documentation (for Zen v1) always talked about the best case scenario (hence the "no less than"). Maybe with Zen v1.5 they've shuffled enough stuff around to bring it to their original target. That is my take.

4.2GHz I think is going to be the new 4GHz.

Funny thing that a mature 14nm or "12nm" process will overclock on par or worse than Broadwell.

Care to share the overclocking numbers with us? I haven't seen any around

Cheers!

 

[juanrga]

You left off the relevant part...these "hacks" all require local (i.e. physical) access to the machine

CTS-labs: "Do these vulnerabilities require physical access? No."

Dan Guido: "no physical access is required"

Additionally...the BIOS hack requires a signed BIOS update...which means someone would have to somehow replicate a board vendors authentication. Which is unlikely to even be plausible.

As mentioned in my former post, they tested that the BIOS hack "works on motherboards by Tyan, ASUS, ASRock, Gigabyte, Biostar, and others." So it is not only plausible but verified.

Not to mention there are no proof of concepts, no code examples, and no information.

As mentioned in my former post there are proof of concepts and a paper full of technical details on the hands of AMD, Microsoft, Symantec, Dell, HP, and others...

Regardless of the hype around the release, the bugs are real, accurately described in their technical report (which is not public afaik), and their exploit code works.

 

[juanrga]

There's an overall reduction of latency, so I would imagine the documentation (for Zen v1) always talked about the best case scenario (hence the "no less than"). Maybe with Zen v1.5 they've shuffled enough stuff around to bring it to their original target. That is my take.

As mentioned in the discussion the older Zen systems were measured to have 12 cycle latency.

Latency in cycles is not the same than latency in ns. That reduction of latency measured in ns for RR/PR is a consequence of those chips running the IMC faster (2933 vs 2666). recall that in Zen systems memory clock is tied to IF clock and so it affects latencies.

 

[-Fran-]

https://www.anandtech.com/show/12556/amd-confirms-exploits-patched-in-weeks

So, there's the official answer. CTS was acting with ulterior motives.

EDIT:

There's an overall reduction of latency, so I would imagine the documentation (for Zen v1) always talked about the best case scenario (hence the "no less than"). Maybe with Zen v1.5 they've shuffled enough stuff around to bring it to their original target. That is my take.

As mentioned in the discussion the older Zen systems were measured to have 12 cycle latency.

Latency in cycles is not the same than latency in ns. That reduction of latency measured in ns for RR/PR is a consequence of those chips running the IMC faster (2933 vs 2666). recall that in Zen systems memory clock is tied to IF clock and so it affects latencies.

All talks about "latency reduction" that I have read are measurements, not cycles. Where did you read that information? Did you even reply in the right forum? haha.

In any case, I didn't sport the "cycle" part in the documents; my mistake.

Cheers!

 

[aldaia]

https://www.anandtech.com/show/12556/amd-confirms-exploits-patched-in-weeks

So, there's the official answer. CTS was acting with ulterior motives.

Contrary to what CTS and Viceroy claimed all exploits will be fixed by software and in a a matter of a few weeks.

AMD is asking for investigation of unusual stock trading.

 

[-Fran-]

https://www.anandtech.com/show/12556/amd-confirms-exploits-patched-in-weeks

So, there's the official answer. CTS was acting with ulterior motives.

Contrary to what CTS and Viceroy claimed all exploits will be fixed by software and in a a matter of a few weeks.

AMD is asking for investigation of unusual stock trading.

I hope that request at least keeps the spooks away... =/

Honestly, I don't think they'll reach a verdict and probably settle outside (if it goes to court), but man...

Anyway! Time to close the CTS Labs chapter!

21st of April was the launch of Zen v1.5?

Cheers!