TR Forums

Ryu Connor wrote:

Looks like it is real.

https://arstechnica.com/information-tec ... uch-worse/

A third party source confirms working proof of concept tools and successful exploitation of all the listed vulnerabilities.

While the fact root is needed is a mitigation, it's not an impossible hurdle (e.g. privilege escalation flaw, social engineering, rogue IT employee), and what makes these vulnerabilities especially dangerous is persistence. Taking off and nuking your OS from orbit will not solve the issue. You will have to throw away hardware to escape the compromise.

For those of you who followed the Spectre and Meltdown thread, you'll remember the discussion turned hardware vulnerabilities being a new battleground for the bad guys. With that in mind I have but one question for you.

Are you not entertained?

Still, Kanter agreed with Guido that the vulnerabilities were a major embarrassment for AMD, particularly because most of them reside in the Platform Secure Processor, which is AMD's version of the secure enclave in the iPhone.

Bauxite wrote:

Also, if I can trick you to run something as administrator or root on any system, its already game over and who gives a damn.

Krogoth wrote:

RMA departments throughout the industry are going to have a massive field day for the next couple of years.

Waco wrote:

Even if it is, surely AMD/Intel/whomever would supply a way to reflash the affected parts.

just brew it! wrote:

Waco wrote:

Even if it is, surely AMD/Intel/whomever would supply a way to reflash the affected parts.

It may only be flashable via a hard-wired JTAG port or somesuch. If so, most end users aren't going to be willing/able to do that.

Waco wrote:

just brew it! wrote:

Waco wrote:

Even if it is, surely AMD/Intel/whomever would supply a way to reflash the affected parts.

It may only be flashable via a hard-wired JTAG port or somesuch. If so, most end users aren't going to be willing/able to do that.

If you can infect it via flashing surely there's a way to clean it up via flashing. At least, it makes sense in my head - just have to exploit the exploit.

Waco wrote:

just brew it! wrote:

Waco wrote:

Even if it is, surely AMD/Intel/whomever would supply a way to reflash the affected parts.

It may only be flashable via a hard-wired JTAG port or somesuch. If so, most end users aren't going to be willing/able to do that.

If you can infect it via flashing surely there's a way to clean it up via flashing. At least, it makes sense in my head - just have to exploit the exploit. :)

ArsTechnica wrote:

The danger of firmware-level malware is that most virus scanners and other anti-malware products focus on RAM and files stored on the desk. It's difficult to detect in the first place, and it's difficult to track it back to its source. It's also tough to remove. "You can't use Thunderstrike to remove Thunderstrike" because the infected firmware patches the security hole in the original firmware.

just brew it! wrote:

That would depend on whether flashing requires support from the existing firmware. If so, the malware could disable the ability to re-flash.

DragonDaddyBear wrote:

https://www.anandtech.com/show/12536/our-interesting-call-with-cts-labs

IC: The standard procedure for vulnerability disclosure is to have a CVE filing and a Mitre numbers. We have seen in the public disclosures, even 0-day and 1-day public disclosures, have relevant CVE IDs. Can you describe why you haven’t in this case?

ILO: We have submitted everything we have to US Cert and we are still waiting to hear back from them.

IC: Can you elaborate as to why you did not wait for those numbers to come through before going live?

ILO: It’s our first time around. We haven’t – I guess we should have – this really is our first rodeo.

YLZ: I think there are pros and cons to both methods. I don’t think that it is a simple question. I think that the advantage of the 30 to 90 days of course is that it provides an opportunity for the vendor to consider the problem, comment on the problem, and provide potential mitigations against it. This is not lost on us.

On the other hand, I think that it also gives the vendors a lot of control on how it wants to address these vulnerabilities and they can first deal with the problem then come out with their own PR about the problem, I’m speaking generally and not about AMD in particular here, and in general they attempt to minimize the significance. If the problem is indicative of a widespread issue, as is the case with the AMD processors, then the company will company probably would want to minimize it and to play it down.

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.

Waco wrote:

Just another reason this smells funny, since AMD could clearly have fixed this via patches prior to them announcing the issue.

derFunkenstein wrote:

YLZ: I think there are pros and cons to both methods. I don’t think that it is a simple question. I think that the advantage of the 30 to 90 days of course is that it provides an opportunity for the vendor to consider the problem, comment on the problem, and provide potential mitigations against it. This is not lost on us.

On the other hand, I think that it also gives the vendors a lot of control on how it wants to address these vulnerabilities and they can first deal with the problem then come out with their own PR about the problem, I’m speaking generally and not about AMD in particular here, and in general they attempt to minimize the significance. If the problem is indicative of a widespread issue, as is the case with the AMD processors, then the company will company probably would want to minimize it and to play it down.

Clearly they had their own agenda they wanted to push and intentionally blindsided AMD in order to do it.

Redocbew wrote:

If the reason for all this is that CTS wanted to "control the narrative", then I'd say they failed at that also.

Instead of AMD having a chance to write their own release everyone else who's been covering this has done all of that for them. In being so focused on what the agenda of CTS may be many of them have gone much farther in downplaying the significance of the threat than AMD probably ever would have on their own.

Ryu Connor wrote:

Not giving time to fix the issue isn't as uncommon as you might imagine.

Ryu Connor wrote:

You mean the same AMD that was roundly criticized on this forum and elsewhere for the fact they disingenuously downplayed their vulnerability to Spectre?

The same company that destroyed the private disclosure window with their high-horse patch submission for Meltdown?

derFunkenstein wrote:

Oh, please. I hate to drag across topics, but you started it. Here's what was said - that AMD CPUs don't do speculative execution across permission levels.
https://lkml.org/lkml/2017/12/27/2

But they'd been talking about this stuff out in the open for weeks
https://lkml.org/lkml/2017/12/4/709

They weren't just rewriting this stuff on a whim. Anybody that's put any thought into this knows that.

Peter Bright wrote:

AMD's behavior before this all went public was also rather suspect. AMD, like the other important companies in this field, was contacted privately by the researchers, and the intent was to keep all the details private until a coordinated release next week, in a bid to maximize the deployment of patches before revealing the problems. Generally that private contact is made on the condition that any embargo or non-disclosure agreement is honored.

It's true that AMD didn't actually reveal the details of the flaw before the embargo was up, but one of the company's developers came very close. Just after Christmas, an AMD developer contributed a Linux patch that excluded AMD chips from the Meltdown mitigation. In the note with that patch, the developer wrote, "The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault."

It was this specific information—that the flaw involved speculative attempts to access kernel data from user programs—that arguably led to researchers figuring out what the problem was. The message narrowed the search considerably, outlining the precise conditions required to trigger the flaw.

For a company operating under an embargo, with many different players attempting to synchronize and coordinate their updates, patches, whitepapers, and other information, this was a deeply unhelpful act. While there are certainly those in the security community that oppose this kind of information embargo and prefer to reveal any and all information at the earliest opportunity, given the rest of the industry's approach to these flaws, AMD's action seems, at the least, reckless.

DancinJack wrote:

https://community.amd.com/community/amd-corporate/blog/2018/03/20/initial-amd-technical-assessment-of-cts-labs-research

moriz wrote:

DancinJack wrote:

https://community.amd.com/community/amd-corporate/blog/2018/03/20/initial-amd-technical-assessment-of-cts-labs-research

"We believe AMD cannot ever fix these issues, so we chose not to give them any time before revealing these vulnerabilities." - CTS Labs

"AMD stock is worth $0 because they cannot ever fix these vulnerabilities." - Viceroy Research

"Fixed." - AMD, one week later.

moriz wrote:

DancinJack wrote:

https://community.amd.com/community/amd-corporate/blog/2018/03/20/initial-amd-technical-assessment-of-cts-labs-research

"We believe AMD cannot ever fix these issues, so we chose not to give them any time before revealing these vulnerabilities." - CTS Labs

"AMD stock is worth $0 because they cannot ever fix these vulnerabilities." - Viceroy Research

"Fixed." - AMD, one week later.