News AMD 'Zenbleed' Bug Allows Data Theft From Zen 2 Processors, Patches Released

[Hotrod2go]

The potential for this is unparalleled.
Is this the beginning of AI generated malware? or has it (AI) been at work in this area for quite some time already?

 

[hotaru.hino]

I believe the point of micro code is that they can alter which micro-ops an instruction decodes to. So, you could potentially devise a microcode-level fix if you can tweak the microcode for AVX instructions to avoid that "XMM Register Merge Optimization2" or somehow prevent VZEROUPPER from getting mispredicted.

I believe microcode affects more how the "plumbing" works in the CPU, rather than how the data is actually processed. If there's something wrong with one of the actual hardware units, then that's something you can't fix.

This is especially the case if the problem was with the design to begin with.

You might also be able to mitigate at the OS level, by trapping certain instructions and emulating their functionality. This could be extremely taxing on performance, however.

This still leaves the issue of the hardware still exhibiting the problem, though this is only really a concern for those with tight security requirements.

 

[bit_user]

I believe microcode affects more how the "plumbing" works in the CPU, rather than how the data is actually processed.

We know the instruction decoder translates instructions into micro-ops. I assume that translation is configurable, but I can't say for sure. It would make sense, as otherwise what you'd be talking about is basically having each part of the CPU being like its own programmable engine which would indeed be inefficient.

If there's something wrong with one of the actual hardware units, then that's something you can't fix.

I didn't say you could fix it. What I said is maybe they can identify a workaround that avoids the "specific timing window" or generating an micro-op sequence resulting a mis-predicted VZEROUPPER instruction.

This still leaves the issue of the hardware still exhibiting the problem, though this is only really a concern for those with tight security requirements.

If they can design an effective workaround using an instruction trap, then the only issue is the performance cost. They can bake the instruction trap directly into the kernel, so that all applications will automatically be affected.

 

[zx128k]

The potential for this is unparalleled.
Is this the beginning of AI generated malware? or has it (AI) been at work in this area for quite some time already?

Thats what researcher's are doing day and night. Using Ai to find security holes.

 

[DSzymborski]

As a general note to the thread, please note that AMD vs. Intel or Nvidia vs. AMD vs. Intel platform wars here, whether outright flame warring, low-key conspiracy offerings, or meta about who is "secretly favoring" one or the other is not going to be a thing that happens here.

 

[TerryLaze]

Aren't consoles zen2?
Hope this gets fixed faster than the similar SQUIP vulnerability.

Noooo, let's hope they can exploit this to hack the consoles.
Of course only for science sake, to make emulators of the new consoles.

Okay, so either disable SMT or just limit it to threads within the same process. Problem solved, right? ...just like most of the other side-channel attacks we've been hearing about.

Yeah lose all of your performance...just don't run anything,problem solved.

 

[bit_user]

Yeah lose all of your performance...just don't run anything,problem solved.

Of course, my preferred solution is the one I underlined: limit core-sharing to threads from the same process. Since the performance-intensive processes tend to have plenty of threads, that should still provide most of the benefits of SMT. In Linux, that feature is called "core-scheduling":

​

Core Scheduling — The Linux Kernel documentation

​

It's been around since the 5.14 kernel, though it really should've come along even sooner. Does anyone know if Windows has an equivalent?

BTW, I'm surprised nobody has mentioned this yet, but another option that Zen 2 desktop users have is simply to upgrade their CPU to a Zen 3-based model, because they're both AM4. Yes, it costs money, but if you want to avoid any potential performance loss from mitigating, it should be mentioned as an option.

 

[TerryLaze]

Of course, my preferred solution is the one I underlined: limit core-sharing to threads from the same process. Since the performance-intensive processes tend to have plenty of threads, that should still provide most of the benefits of SMT. In Linux, that feature is called "core-scheduling":

​

Core Scheduling — The Linux Kernel documentation

​

It's been around since the 5.14 kernel, though it really should've come along even sooner. Does anyone know if Windows has an equivalent?

You can inject code into a process this wouldn't protect you from anything.

Process Injection: Thread Execution Hijacking, Sub-technique T1055.003 - Enterprise | MITRE ATT&CK®

attack.mitre.org

PS:in windows core scheduling is called affinity mask.

 

[bit_user]

You can inject code into a process this wouldn't protect you from anything.

Process Injection: Thread Execution Hijacking, Sub-technique T1055.003 - Enterprise | MITRE ATT&CK®

attack.mitre.org

In order for that to be relevant, please cite a known instance of process injection which both:

1. Is vulnerable to remote unprivileged code.
2. Is not currently mitigated or fixed.

Otherwise, I think my point stands.

PS:in windows core scheduling is called affinity mask.

That exists in Linux, also (or numactl, if you want to do it from the commandline). What I'm talking about is a feature whereby the kernel will automatically prevent threads from different processes from getting scheduled on the same core. Like the Linux feature, in the link I provided.

 

[plausible_deniability]

For once, I feel good that my Ryzen 5 2600X Zen+ is just old enough architecture to predate Zen2, I think.

 

[domih]

After reading the description (the OP) there: https://lock.cmpxchg8b.com/zenbleed.html, I went for the POC there: https://lock.cmpxchg8b.com/files/zenbleed-v5.tar.gz.

I tried the POC on 3960X (Zen 2) and 5950X (Zen 3) using Ubuntu 20.04 and 22.04 respectively. The former is affected and leaks data like a password entered during a sudo, the latter is not affected.

As described in the OP, I then tried the workaround using the msr-tools commands: wrmsr -a 0xc0011029 $(($(rdmsr -c 0xc0011029) | (1<<9))) as root. After that the 3960X was no longer affected (zenbleed was no longer printing leaks.) As the OP says: This may have some performance cost. I did not test this aspect.

I could not find more information about the DE_CFG[9] bit. Just to learn about it.

So while waiting for the next AGESA in October, I'll use the workaround.

 

[bit_user]

As described in the OP, I then tried the workaround using the msr-tools commands: wrmsr -a 0xc0011029 $(($(rdmsr -c 0xc0011029) | (1<<9))) as root. After that the 3960X was no longer affected (zenbleed was no longer printing leaks.) As the OP says: This may have some performance cost. I did not test this aspect.

OMG, what does it do? Do we know? Or is that the DE_CFG[9] bit you mentioned not being able to find out about?

It'd be interesting if you tried the core scheduling feature I mentioned (i.e. without the MSR workaround you mentioned).

 

[mambateqrules]

The discovery of vulnerabilities and the responsible disclosure by security researchers play a crucial role in enhancing the overall security of the technology ecosystem. Users should stay informed about such developments and take necessary precautions, such as regularly updating their software, to stay protected from potential security risks, whereas a pc gamer might be vulnerable to this flaw but it depends how crucial your data is compared to big tech companies.

 

[domih]

That was fast, apt update this morning showed on the 3960X:

...$ apt changelog amd64-microcode
amd64-microcode (3.20191218.1ubuntu1.1) focal-security; urgency=medium

* SECURITY UPDATE: Zenbleed - information leak via speculative execution
- microcode_amd_fam17h.bin{.asc}: update AMD fam17h cpu microcode and
signature for Zenbleed vulnerability
- New microcodes:
+ Family=0x17 Model=0x31 Stepping=0x00: Patch=0x0830107a Length=3200 bytes
+ Family=0x17 Model=0xa0 Stepping=0x00: Patch=0x08a00008 Length=3200 bytes
- Updated microcodes:
+ Family=0x17 Model=0x08 Stepping=0x02: Patch=0x0800820d Length=3200 bytes
+ Family=0x17 Model=0x01 Stepping=0x02: Patch=0x0800126e Length=3200 bytes
- CVE-2023-20593

On my machine, lscpu shows:
.../...
CPU family: 23 <-- 0x17
Model: 49 <-- 0x31
.../...
Stepping: 0
.../...

I applied it. No more zenbleed after reboot.

More info there: https://seclists.org/oss-sec/2023/q3/63

 

[domih]

OMG, what does it do? Do we know? Or is that the DE_CFG[9] bit you mentioned not being able to find out about?
.../...

The latter, just wondering what bit #9 of DE_CFG is and does. Anyway, see above, there is already an AMD firmware update circulating via apt.

For the "chicken bit" I found more info there: https://www.phoronix.com/news/Linux-AMD-Spectral-Chicken

<<...We've had enough fun with the spectral chicken bit - name it what it really does: it suppresses non-branch predictions...>>

Plus: https://lkml.org/lkml/2023/4/25/841

 

[domih]

Finally I can confirm the limited set of family/model that get the fix from today's amd64-microcode patch.

I just apt updated a system with a 4750g, zenbleed still leaks after reboot. On the other hand the msr-tools workaround is operative, after running the cryptic commands, zenbleed no longer leaks.

That's it for me, I don't have a Mendocino laptop (https://www.tomshardware.com/news/amd-ryzen-athlon-7020-apu-specs-mendocino) to try today's amd64-microcode patch.

Extra Notes:
- Tested 5700g (Zen 3), it is not affected.
- Tested Threadripper 2950X (Zen+, family: 23/0x17, Model: 8/0x08, Stepping: 2/0x02), it is not affected.

 

[Hartemis]

For future hybrid architectures, I wish dedicated security cores, without SMT, no branch prediction, constant-time execution and so on... (no out-of-order?) and with specific security features and reinforcement.
Operating systems will have to select these cores to run sensitive programs, such as encryption or keys management, and software developers will be able use specific instructions to indicate that "this piece of code can be executed on a trusted cores, if available".
And so, P-Cores can be further optimized for performance, with little regard for security.

 

[bit_user]

For future hybrid architectures, I wish dedicated security cores, without SMT, no branch prediction, constant-time execution and so on... (no out-of-order?) and with specific security features and reinforcement.
Operating systems will have to select these cores to run sensitive programs, such as encryption or keys management, and software developers will be able use specific instructions to indicate that "this piece of code can be executed on a trusted cores, if available".

Interesting idea. Perhaps the P-cores can be put in a special mode to disable branch prediction and speculation. As for SMT, the OS can simply avoid running a second thread on it, during the time the sensitive one is there.

And so, P-Cores can be further optimized for performance, with little regard for security.

I doubt it, because not every security-sensitive thread will be flagged as such.

 

[JamesJones44]

Interesting idea. Perhaps the P-cores can be put in a special mode to disable branch prediction and speculation. As for SMT, the OS can simply avoid running a second thread on it, during the time the sensitive one is there.

I don't think that is that far of a stretch. Thread Director already kind of works like that based on workload types and can be configured (to a degree). Something like a "Security Director" could work with the OS to direct sensitive content to pre-configured cores or disable some features while the branch is active.

 

[tamalero]

A hostile ad running in a web browser, while you log into your bank account (or other sensitive accounts) could steal your password. If that bothers you, then you might want to disable SMT or use a different PC for your financial activities or anything else you deem sensitive.


That's what we used to think, but you know ransomware can hit everyday users too, right? And people's banking details are bought and sold on the dark web, en masse.

Yikes, and considering even google ads and many other ad managers have been victims( or being negligent) to host infected ads in their platforms.
This def looks crazy as hell!

Thank god I upgraded to a 5700G ( Zen3) for my my home lab server.

 

[CVZ]

I find really sad that AMD has publicly acknowledge this serious security hardware vulnerability , and have no urgency in releasing a patch for their consumer CPUs, it's 5 months to December, plenty of time to release malware and web pages with "keylogger" just waiting for you to open your online bank account. And what will be the performance hit of the patch. Legislation really have to change, tech world has too many defective hardware being sold!

 

[zx128k]

I find really sad that AMD has publicly acknowledge this serious security hardware vulnerability , and have no urgency in releasing a patch for their consumer CPUs, it's 5 months to December, plenty of time to release malware and web pages with "keylogger" just waiting for you to open your online bank account. And what will be the performance hit of the patch. Legislation really have to change, tech world has too many defective hardware being sold!

I think 5 months is an expedited time frame. fTPM can be fully compromised (AMD PSP) as well and as far as I understand that cannot be fixed. At least this has a chance of being fixed. I have a 3800xt/x570 system I would like to use.

 

[hotaru.hino]

For future hybrid architectures, I wish dedicated security cores, without SMT, no branch prediction, constant-time execution and so on... (no out-of-order?) and with specific security features and reinforcement.

Processors and computer systems already have dedicated security enclaves. Examples include AMD PSP, Intel Management Engine, ARM TrustZone, and Apple T2.

A common theme I see in these vulnerabilities is leaking processor state inappropriately. If you want to go to the extreme, you'd have to create a purely functional (stateless) processor... but that doesn't really solve anything because it's impractical to have a stateless system. That state has to live somewhere.

Operating systems will have to select these cores to run sensitive programs, such as encryption or keys management, and software developers will be able use specific instructions to indicate that "this piece of code can be executed on a trusted cores, if available".

Like Intel's infamous TSX?

 

[zx128k]

Im still on a 2 year old BIOS. Im not upgrading. Ya, my PC is vulnerable, to who? The random guy that's going to pick me out of a billion people and somehow know that I have a Zen 2 chip. Ya, these vulnerabilities exist, but in practice they are completely irrelevant, unless your a big datacenter/big company with sensetive data. A home PC gamer shouldn't be worried

Hackers do that to create botnets. They create a website for example which you visit or an email with a payload. They then use the botnet as a cover to make attacks. DDOS is one such attack, also sending out waves of spam emails.

Maybe this is were anti-virus software or ad-malware software can help. Addin an adblocker and a blacklist of ad servers. Using ads as a method of attacking computers is nothing new. Its been done in the past.

This issue will be likely stopped with anti-virus software. Businesses can block stuff with deep packet inspection. Also a firewall helps with blocking it phoning home. So if you have decent security, I guess or hope everyone will be okay.

It bad that there's a security issue but its never the end of the world. For people that must have great security to comply with laws. Then this is an issue they must resolve for compliance reasons. There have always been zero day attacks and there will always be zero day attacks.

 

[bit_user]

Processors and computer systems already have dedicated security enclaves. Examples include AMD PSP, Intel Management Engine, ARM TrustZone, and Apple T2.

Those security cores can't run application-level threads, which is what @Hartemis seems to be talking about. In the case of x86, they're even a different ISA.

A common theme I see in these vulnerabilities is leaking processor state inappropriately. If you want to go to the extreme, you'd have to create a purely functional (stateless) processor... but that doesn't really solve anything because it's impractical to have a stateless system. That state has to live somewhere.

Memory-to-memory architecture have been done, in the past. Since some of the side-channel attacks exploited the cache hierarchy, you'd also have to go without, which would really trash performance. ...unless, all the RAM it used was on-die SRAM, in which case it'd have the speed of cache without the potential for leakage. The main problem would then be the size/cost tradeoff.

Like Intel's infamous TSX?

Huh? No, that's something different. That's for transactional sequences and lock elision.

In the imagined scenario, I think there'd just be an API call to tell the OS "Hey, I'm entering a sensitive section". At that point, it blocks the thread until you're running on a core configured for maximum security, migrating the thread if necessary. When you're done, just tell the OS with a corresponding call. The OS could manage whatever needs to happen at the hardware level. Like, if there's a switch to disable speculation and branch prediction, the OS could toggle it. If the thread needs to be migrated, or a peer needs to be suspended, that could happen too.