News World's first CPU-level ransomware can "bypass every freaking traditional technology we have out there" — new firmware-based attacks could usher...

[Makaveli]

This is why I tell people to never buy AMD gear of any type. My former reason was it's buggy, and here is a brand new, much better reason not to build a computer around it. This is downright FRIGHTENING. I always wondered if this was possible, and AMD has made it so.

nice troll bait.

Do better!

 

[jp7189]

Rule number two: Hire a security expert. Nothing is worse than a false sense of security.

A false sense of insecurity is a close second. I've met a few 'security' practitioners that sell nothing but paranoia because it pays the best.

 

[jp7189]

This is why I tell people to never buy AMD gear of any type. My former reason was it's buggy, and here is a brand new, much better reason not to build a computer around it. This is downright FRIGHTENING. I always wondered if this was possible, and AMD has made it so.

Intel ME malware was worse than this. Also this researcher is talking about poc code. That doesn't speak to how easy or practical it is to implement in real world systems.

 

[rluker5]

The people who matter already know this. Infected microcode can probably disable memory encryption and even inter-process protection features, allowing one process or guest VM to eavesdrop on another. This makes it a very big deal, for cloud operators.

You know I like beating that still not dead horse so I will again: SQUIP bypasses all default encryption and inter-process protection features and allows one process or guest VM to eavesdrop on another:

SQUIP Side Channel Attack Rattles AMD’s Zen Cores

The majority of AMD’s CPU lineup – essentially any processor using Zen 1, Zen 2, or Zen 3 cores with simultaneous multithreading (SMT) enabled – is

www.nextplatform.com

Doesn't have AMD provided mitigation - you have to make your own:
https://www.amd.com/en/resources/product-security/bulletin/amd-sb-1039.html
And can be exploited purely in website javascript in updated modern browsers, invisibly, without leaving a trace, or being picked up by antivirus merely by visiting the wrong site:
https://stefangast.eu/papers/javasquip.pdf

No microcode infection needed. Just run Zen normally with SMT enabled.
To be fair Intel has a similar, but mitigated vulnerability with HT.

Rule number one if you require a secure device: Wipe everything, including the UEFI firmwares, and overwrite them with newer or same versions.

Same with your hard drives - empty space can also contain viruses (Re: Volume Shadows, Snapshots, etc.); wipe the whole drive, not just a 'quick format'.

Rule number two: Hire a security expert. Nothing is worse than a false sense of security.

Rule number 3: disable SMT on Zen.

Rather opinionated, aren't we. Obviously you just see AMD products as lower quality, with anything to back that up as another affirmation (referring to affirmation bias, which we all have to be fair). I'm not here to try to change anyone's mind, but I'm going to bring some data and some thoughts to table.

Intel has been far more impacted by Speculative Execution flaws (Spectre, Meltdown, etc.) than AMD. Here's a nice lil list:

1. Meltdown (CVE-2017-5754)

2. Spectre Variants
Variant 1 (CVE-2017-5753): Bounds check bypass.
Variant 2 (CVE-2017-5715): Branch target injection.
Variant 4 (CVE-2018-3639): Speculative store bypass.
Variant 3a (CVE-2018-3640): Rogue system register read.
Variant 1.1/1.2: More nuanced Spectre-style flaws.

3. Foreshadow (L1TF - CVE-2018-3615, -3620, -3646)

4. ZombieLoad (CVE-2018-12130, etc.)

5. RIDL, Fallout (MDS family)

6. SRBDS / "CrossTalk" (CVE-2020-0543)

7. Snoop-Assisted L1 Data Sampling (CVE-2020-0550)

8. Processor Diagnostic Leak (CVE-2022-21123, etc.)
> Collectively known as "MMIO Stale Data" vulnerabilities.


** Now, AMD's list: **


1. Spectre Variants

Variant 1 (CVE-2017-5753): Confirmed.
Variant 2 (CVE-2017-5715): Confirmed.
Variant 4 (CVE-2018-3639): Confirmed.

2. Take A Way (CVE-2020-12965)

Note: AMD doesn't consider this a practical vulnerability

3. Transient Execution of Non-Canonical Accesses

4. Branch Type Confusion (CVE-2022-23825)


Notice that Meltdown isn't on AMD's list. This is due to their use of stronger isolation mechanism. Most of these vulnerabilities are nullified or mitigated by CPU microcode updates, OS updates, or both. Many of these are now mitigated in hardware, requiring no updates and resulting in a much smaller performance hit when mitigations are enabled in firmware and/or the OS.

AMD has confidential cloud computing clients -- these aren't your average Tom, Dick, and Joe. Most don't update their motherboard BIOS/UEFI, so many folks in either camp are theoretically vulnerable to what are fortunately difficult attacks to carry out successfully. Of course, Windows Update now pushes BIOS/UEFI updates when OEM's upload those updates, so it's probably getting better but still only marginally so.

Lastly, the Intel 13th and 14th gen idle voltage killing CPU's debacle kind of blows a whole in your "AMD is buggy" assertion. In case you are unfamiliar with it:
https://www.theregister.com/2024/11/06/intel_sued_over_raptor_lake_chips/

All tech devices are buggy sometimes. Just realize bugs are most common in software code, not hardware.

Intel is better at providing mitigations though. Their vulnerabilities are mitigated while AMD's sometimes are just ignored and you have to live with an insecure pc. In addition to what I mentioned above, AMD keeps moving out the date to implement the Leftover Locals vulnerability mitigation on anything consumer that has an AMD dGPU or iGPU. Now it is June 2025 when it was originally supposed to be March 2024. A couple of months ago it was April 2025.: https://www.techpowerup.com/317927/...s-llm-security-on-apple-amd-and-qualcomm-gpus https://www.amd.com/en/resources/product-security/bulletin/amd-sb-6010.html


Also, why is an Intel CPU shown in an AMD security problem article?

 

[rluker5]

An interesting twist: I wonder if a microcode corruption can blow some of these fuses and brick your AMD CPU like a vendorless variant of this? https://www.servethehome.com/lenovo-vendor-locking-ryzen-based-systems-with-amd-psb/

Not much to gain in a ransomware setting there because the victim would permanently lose the functionality of their CPU so it probably won't happen.

 

[rpcy]

Rapid7's Christiaan Beek has taken CPU ransomware to proof of concept.

World's first CPU-level ransomware can "bypass every freaking traditional technology we have out there" — new firmware-based attacks could usher... : Read more

Even the engineers whose jobs it is to write microcode have to understand the microcode format, the machine resources at that level, the syntax, the rules about what operations can proceed in the presence of other ongoing ops, and much much more. I do not doubt that if the basic security/sanity checks have been circumvented, and some minimal knowledge is present for how to get one's bogus ucode patch to be engaged during runtime, that one can cause the processor to malfunction in some random way. But I'm dubious about the idea that one can somehow intuit how to write one's own working microcode with no access to the ucode documentation and tools. With all of that in mind, we were extremely careful about access to the ucode documents when we first did ucode patches with Intel's P6 in the early 1990's.

 

[nogaard777]

Pretty much all these vulnerabilities since specter and meltdown are near meaningless to normal users and only apply to servers where you need to trust who had access to your hardware, because they all require physical access to the hardware.

If a shady character has physical access to your PC you have far bigger security issues than them running shady code on it. This is why businesses usually have their servers locked up tight with limited access for only the most trusted employees.

These websites just love to exaggerate vulnerabilities for the clicks.

 

[husker]

"According to the report, Beek has indeed written proof-of-concept code for ransomware that can hide in a CPU. Reassuringly, he promises they won't release it."

Gain of function research.

 

[rluker5]

Pretty much all these vulnerabilities since specter and meltdown are near meaningless to normal users and only apply to servers where you need to trust who had access to your hardware, because they all require physical access to the hardware.

If a shady character has physical access to your PC you have far bigger security issues than them running shady code on it. This is why businesses usually have their servers locked up tight with limited access for only the most trusted employees.

These websites just love to exaggerate vulnerabilities for the clicks.

This one doesn't require physical access, administrative authority, or even a UAC prompt, but is for some reason ignored by tech media: https://stefangast.eu/papers/javasquip.pdf which came from https://www.nextplatform.com/2022/08/11/squip-side-channel-attack-rattles-amds-zen-cores/

But nobodies are probably at pretty low risk of having their passwords, RSA keys, crypto wallets etc stolen by someone using it as evidenced by there not being a fuss about it for the last couple years. Businesses on cloud providers have more to worry about.

 

[johnmikeofficial]

Was his proof of concept ported to Linux?

I think it will as it's cpu based.

 

[Kidd N]

Rapid7's Chrstiaan Beek has written proof-of-concept code

From that it's telling me that in theory it could work, but still has not been done.
So nothing to see move along.

How does that tell you it hasn't been used, the written proof-of-concept code just tells you a non evil entity thought of it. What in that equation tells you it wasn't already used in the wild?

This would not be something that is sniffed out by any conventional security software, and unless you knew the values you were looking for (a tip off,) I don't even know how you could prove a device was infected with out know where exactly to examine in the CPU's output...

 

[bit_user]

I'm dubious about the idea that one can somehow intuit how to write one's own working microcode with no access to the ucode documentation and tools.

There's not "no documentation and tools". Google already published a fair amount of their initial reverse engineering. I assume further crowd-sourced discoveries are being collected somewhere, but I haven't looked for anything of the sort.

https://bughunters.google.com/blog/5424842357473280/zen-and-the-art-of-microcode-hacking
​

 

[bit_user]

No microcode infection needed. Just run Zen normally with SMT enabled.

That's a false equivalence, since that vulnerability merely allows eavesdropping. With hacked microcode, you can potentially do a lot more than that.

Rule number 3: disable SMT on Zen.

That vulnerability affected only up through Zen 3 cores.

Intel is better at providing mitigations though.

They need to be!
: D

Their vulnerabilities are mitigated while AMD's sometimes are just ignored and you have to live with an insecure pc.

It's happened a couple times, on older CPUs no longer under warranty.

In addition to what I mentioned above, AMD keeps moving out the date to implement the Leftover Locals vulnerability mitigation on anything consumer that has an AMD dGPU or iGPU. Now it is June 2025 when it was originally supposed to be March 2024.

That's just failing to clear out GPU memory, affecting only cases where you have sensitive data in your GPU. The CVE is classed as:

Potential Impact: Data leakage
Severity: Medium
​

Furthermore, the description seems to imply that an exploit requires privilege escalation, or must somehow otherwise circumvent driver-level protections.

Also, why is an Intel CPU shown in an AMD security problem article?

Yup. I caught that, also. Sloppy use of stock footage, I guess.

 

[bit_user]

"According to the report, Beek has indeed written proof-of-concept code for ransomware that can hide in a CPU. Reassuringly, he promises they won't release it."

Gain of function research.

This is not really different than any other cybersecurity researchers' work in hunting for vulnerabilities. It's standard practice to try and devise an exploit, whenever one is found, in order to prove that the vulnerability isn't merely theoretical. Also, most data-leakage exploits now characterize the rate at which data can be leaked (which requires a sample exploit).

I think it's an old debate, in the cybersecurity industry, with consensus having consolidated around current practices. It's been shown that manufacturers don't take reports seriously, unless the feasibility of an exploit has actually been demonstrated.

In this case, I think we didn't really need to proof beyond what Google showed, but I wouldn't say it had no value. I wish the article had been clearer about exactly what the researcher accomplished.

 

[bit_user]

This would not be something that is sniffed out by any conventional security software, and unless you knew the values you were looking for (a tip off,) I don't even know how you could prove a device was infected with out know where exactly to examine in the CPU's output...

What you can look for is a vector for the infected microcode to get loaded, in the first place. Like hacked UEFI. Such a hack could be self-deleting, but that would mean the infected microcode is gone after you reboot your machine.

 

[rluker5]

You guys already post at least one over-hyped, negative article about Intel every day. Is it really necessary to add a recap of every one of them to every one of them? Is it a requirement for you all to append this summary? Is there a word count requirement? Do you guys get paid per word?

Maybe I’m in the minority, but please just post the facts. Here’s the tl;dr

Intel posted some security vulnerability notices. They’ve been patched for at least 7 months now. Be sure to update drivers if you haven’t yet.

That's a false equivalence, since that vulnerability merely allows eavesdropping. With hacked microcode, you can potentially do a lot more than that.

You are correct that a hacked microcode can do a lot more than an eavesdropping vulnerability, but letting sensitive data fall into the wrong hands is still a security concern.

That vulnerability affected only up through Zen 3 cores.

Zen 4 released on Sep 27 2022 and AMD updated the security bulletin to include Zen 4 on Dec 18 2023, about 5 quarters later. Per AMD: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-1039.html Zen 5 was released on Aug 15, 2024 so AMD is due to add it to this list sometime before Christmas this year. And since AMD hasn't changed their multiple CPU scheduler+SMT approach, I see no reason that Zen 5 won't make the list.

They need to be!
: D

Fair enough.

It's happened a couple times, on older CPUs no longer under warranty.

I'm not talking about SinkClose, in currently sold CPUs and GPUs I've given 2 examples already. No normal consumer is going to rewrite their software to deal with SQUIP so the only mitigation is SMT off, and also that Leftover Locals vulnerability on all AMD consumer dGPUs and iGPUs was expanded to Whispering Pixels: https://arxiv.org/pdf/2401.08881
https://www.amd.com/en/resources/product-security/bulletin/amd-sb-6013.html
Which does what it says, reads pixels left in GPU memory, and "Our attacks require the attacker to execute a malicious user application. Beyond this, no special privileges for the attacker application are needed." - from first link. This Whispering Pixels attack is also unpatched, but the patch should be the same driver that fixes Leftover Locals, but it's use seems like it will be optional. I wonder if these mitigations will ever be tested for those who place a high value on security?

Yup. I caught that, also. Sloppy use of stock footage, I guess.

Right now, for the average person these obscure vulnerabilities don't pose much of a threat. But what if hacking got a little more delegated to AI? Tirelessly persistent and only limited in effort by profitability.

 

[bit_user]

Zen 5 was released on Aug 15, 2024 so AMD is due to add it to this list sometime before Christmas this year. And since AMD hasn't changed their multiple CPU scheduler+SMT approach, I see no reason that Zen 5 won't make the list.

Yes, they have changed their SMT implementation. Zen 5 has a split-decoder that devotes one 4-way decoder per SMT thread. That's new as of Zen 5. In Chips & Cheese' interview with Mike Clark, he also talked about other hardware resources that are dedicated per SMT thread.

In general, Zen 5 was characterized as a major reworking of their micro-architecture. So, probably a lot got touched that should create a break with prior Zen cores. While I'm sure some stuff got carried over (and the microcode signing is an example of that), it shouldn't be the default assumption that something affecting earlier Zens will also affect 5 and beyond.

Leftover Locals vulnerability on all AMD consumer dGPUs and iGPUs was expanded to Whispering Pixels: https://arxiv.org/pdf/2401.08881
https://www.amd.com/en/resources/product-security/bulletin/amd-sb-6013.html
Which does what it says, reads pixels left in GPU memory,

No, not GPU memory. It's talking about on-chip GPU registers, which is much more limited and makes the exploit even more dependent on targeting a specific application. Most of the security-sensitive stuff happens on your CPU.

it's use seems like it will be optional.

That doesn't make sense. If AMD releases a driver-level fix, then everyone who gets the driver will have the fix. Unlike motherboard BIOS fixes, which need to be adopted and released by the motherboard maker, AMD GPUs all use AMD's official driver.

 

[rluker5]

Yes, they have changed their SMT implementation. Zen 5 has a split-decoder that devotes one 4-way decoder per SMT thread. That's new as of Zen 5. In Chips & Cheese' interview with Mike Clark, he also talked about other hardware resources that are dedicated per SMT thread.

In general, Zen 5 was characterized as a major reworking of their micro-architecture. So, probably a lot got touched that should create a break with prior Zen cores. While I'm sure some stuff got carried over (and the microcode signing is an example of that), it shouldn't be the default assumption that something affecting earlier Zens will also affect 5 and beyond.

The point being AMD still has multiple CPU schedulers and SMT makes them still vulnerable to this attack since those are the requirements. Even Apple would be vulnerable if they implemented SMT.

No, not GPU memory. It's talking about on-chip GPU registers, which is much more limited and makes the exploit even more dependent on targeting a specific application. Most of the security-sensitive stuff happens on your CPU.

It is more limited, but probably still less secure to use an AMD d or iGPU than it is to use that AI Recall "feature" that constantly snapshots your screen because that is supposedly secure.

That doesn't make sense. If AMD releases a driver-level fix, then everyone who gets the driver will have the fix. Unlike motherboard BIOS fixes, which need to be adopted and released by the motherboard maker, AMD GPUs all use AMD's official driver.

You are right that is doesn't make sense, but, per AMD: "

Mitigation​

AMD has created a new operating mode designed to prevent processes from running in parallel on the GPU, and to clear registers between processes on supported products. This mode is not enabled by default and needs to be set by an administrator. AMD expects performance impacts if the new mode is enabled in environments where multiple processes would have been running simultaneously on the GPU. The performance impact will be related to the number of processes that would have been running in parallel. Additionally, a lesser performance impact may arise due to the additional clearing of registers between processes."
From: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-6010.html

The failure to fix the vulnerabilities is intentional. Probably bad for pr or sales or something.

 

[Krieger-San]

A false sense of insecurity is a close second. I've met a few 'security' practitioners that sell nothing but paranoia because it pays the best.

Agreed! Gotta find that 'Lagom' level of reality; you do your best to stay abreast of the tidal wave of crap, updating configs to stay as safe as possible while also preparing for the worst.
"Hey boss, how's your business insurance? Have ransomeware protection? Does it cover a breach coach?"
If the answer isn't yes, you're not as prepared as you could be for a very stressful, quite possibly traumatizing, experience.

 

[Krieger-San]

In general, your filesystem would have to mess up (either due to a freak data error or a software bug), in order for anything in "blank space" to get returned. Furthermore, if it's a SSD, the TRIM command takes care of "garbage collecting" empty blocks. I'm not sure exactly what different SSDs do, when you read a block the drive thinks is empty, but I'd guess you generally see it as all zeros.

That said, if the drive has a "secure erase" feature, it's easy and a no-brainer just to do it.

Mostly referring to spinners when it comes to wiping; or non dynamic virtual disks. Trim/ discard and free space consolidation would certainly help wipe out some pesky code