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

[Admin]

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

 

[edzieba]

Ah warned ye!

Ransomware is a really benign exploit in this case. With unfettered and effectively invisible owning of the CPU, you can insert much more subtle and nefarious malware. For example, you could modify every encryption call to a random value in a way that returns apparently random values that are instead deterministic. An attacker than insert this malware into a CPU, and then be able to decrypt every piece of plaintext that passes through that CPU, with no obvious way to know this is occurring (i.e. not just returning a static value for every call for a random one).

 

[jp7189]

I'm not clear on where this resides. Does this actually alter the CPU chip itself and ride along if it's moved to a new motherboard? Or does it alter the BIOS chip of the motherboard to patch CPU microcode at runtime?

 

[bit_user]

Beek has indeed written proof-of-concept code for ransomware that can hide in a CPU.

Not exactly sure what he means by this. As mentioned in the prior articles about Zen's microcode signing vulnerability, the CPU's microcode is reset upon reboot. So, the malware cannot reside there, across reboots. The exploit must involve some other hack, such as infecting UEFI.

I guess, one way you could use hacked microcode to hide malware is by relying on the microcode to interpret seemingly benign code in a malicious way. This could render whatever footprint the malware might have on the system virtually invisible to malware scanners.

 

[bit_user]

Does this actually alter the CPU chip itself and ride along if it's moved to a new motherboard?

No. Something would have to reload it into the CPU, every time the machine boots.

 

[bit_user]

With unfettered and effectively invisible owning of the CPU, you can insert much more subtle and nefarious malware.

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.

 

[jp7189]

No. Something would have to reload it into the CPU, every time the machine boots.

So, based on that, replacing the motherboard of possible refreshing the BIOS would fix it. I'm thinking of CPUs on the secondary market and how this would affect; could they be precompromised at time of sale?

If this is in the BIOS chip how is it much different from other BIOS/firmware level malwares that we've had for ages? Those run before the OS and have (seemingly) the same capabilities as described in the article. I feel like I'm not getting what this researcher is saying.

 

[bit_user]

I'm thinking of CPUs on the secondary market and how this would affect; could they be precompromised at time of sale?

The information in prior articles on this subject assured us that the microcode inside the CPU is immutable.

I feel like I'm not getting what this researcher is saying.

The CPU's microcode can alter the way its instruction decoders interpret the instruction opcodes it executes. So, he probably devised some clever way to use this phenomenon to enable the malware package on disk to evade detection.

It's perhaps not inconceivable that a highly-targeted malware can avoid having any external footprint, aside from the hacked UEFI package which loads it in. But, microcode has limitations and so it would have to be an attack intended to modify something a very specific program does, which opens it up to external attacks.

 

[adamXpeter]

We hope he open sourced his work to support real science

 

[Krieger-San]

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.

 

[DingusDog]

Most likely requires physical access to the machine in which case you're already compromised. I'm not too worried.

 

[bit_user]

Most likely requires physical access to the machine in which case you're already compromised. I'm not too worried.

No and no.

On the first point, just loading compromised microcode into the CPU is possible with admin privileges or if you can find some other way to modify UEFI. No physical access required.

The second "no" has to do with a hosted environment. Modern server CPUs support memory encryption, which protects the privacy of tenants from even the admin who's operating the host. With hacked microcode, that encryption can be compromised, which then enables spying on the tenants.

 

[bit_user]

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'.

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.

 

[Zerk2012]

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.

 

[Aiodensghost]

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.

Has not been done yet isn't a reason to blatantly dismiss what can become a major threat if left unknown. Proof of concept right now, but I bet you that those hacker's in the Discord are gonna be looking into it.

 

[daveskynet]

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.

 

[Zerk2012]

Has not been done yet isn't a reason to blatantly dismiss what can become a major threat if left unknown. Proof of concept right now, but I bet you that those hacker's in the Discord are gonna be looking into it.

You don't think they been trying to do something like that for years?

 

[ezst036]

Was his proof of concept ported to Linux?

 

[acadia11]

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 would you know if it’s been done or not? That’s kind of the point … because we aren’t looking for it currently. My question is if AV can’t detect it, how would you write a firmware AV that could detect it. Probably the simpler solution is to to just plug the microcode and exploit.

 

[ejolson]

In my opinion user-programmable microcode is a good idea and could be used, for example, to speed up emulation and other tasks.

Seen another way the problem here is not that a user was able to load customised microcode, but that there is so much encryption and obfuscation involved in the boot processes that nobody, not even the writers of antivirus software, know how to audit the microcode being loaded at boot time. In particular, the solution to this problem is not more obfuscation but instead a transparent and third-party-auditable boot process.

 

[bit_user]

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.

They fixed it, though. Update your motherboard BIOS and then you're protected.

 

[bit_user]

In my opinion user-programmable microcode is a good idea and could be used, for example, to speed up emulation and other tasks.

Microcode has the ability to break protection mechanisms in the OS or hypervisor. It might be fun to twiddle around with, but the security implications are too severe for this to be allowable on the typical system.

From the CPU vendor's perspective, they don't want to enable it, because the instruction set hides a lot of complexity, as well as bug fixes, mitigations, and workarounds. The point of even having updatable microcode is precisely so they can do that sort of stuff.

The software analogy would be that an ISA is like an API. The vendor wants to support their official API. They designed it to fit a certain usage model and their implementation supports that. If you try to peel back their API and interface with their code at a lower level, the complexity and fragility increases substantially, as would the support burden.

Seen another way the problem here is not that a user was able to load customised microcode, but that there is so much encryption and obfuscation involved in the boot processes that nobody, not even the writers of antivirus software, know how to audit the microcode being loaded at boot time. In particular, the solution to this problem is not more obfuscation but instead a transparent and third-party-auditable boot process.

That's not accurate. The issue was a weakness in the cryptographic signing of the microcode packages, at the CPU level. When you load microcode into the CPU, it checks the signature to verify that it's truly from AMD.

Google found a weakness in it, which allowed them to load modified microcode. They publicized it, once AMD had released a fix to their partners. Get the latest BIOS for your motherboard, to make sure you're protected.

Anyway, the issue isn't anything fundamentally to do with the boot process, itself.

 

[DS426]

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.

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.

 

[DS426]

In my opinion user-programmable microcode is a good idea and could be used, for example, to speed up emulation and other tasks.

Seen another way the problem here is not that a user was able to load customised microcode, but that there is so much encryption and obfuscation involved in the boot processes that nobody, not even the writers of antivirus software, know how to audit the microcode being loaded at boot time. In particular, the solution to this problem is not more obfuscation but instead a transparent and third-party-auditable boot process.

Yeah... I'm going to say leave that for RISC-V (and not your high-end chips but "tinker-friendly" ones). All of the proprietary ISA's have good reason to be locked down, as @bit_user pointed out.

 

[DS426]

We hope he open sourced his work to support real science

*Responsible* disclosure is kind of important too, so probably not yet; better to ensure there's more time to update systems. Sharing in small, trusted circles, sure, so as to speed up attack scenarios and evaluate for feasibility, practicality, reliability, PoC alterations, persistence mechanisms, and so on.