Zenbleed - CVE-2023-20593

[arthdark]

Hello,

any updates regarding the Zenbleed vulnerability?

https://lock.cmpxchg8b.com/zenbleed.html
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-20593

Any update on the microcode package?

 

[aaron]

If you need it quickly and your vendor does not provide a newer BIOS with current µcode updates, a recent version is available in Debian unstable (3.20230719.1): https://packages.debian.org/search?...hon=names&suite=all&section=non-free-firmware

 

[reflect]

I would also be interested about updates regarding that. As per the Security Bulletin from AMD it seems like the microcode update just patches the 2nd Gen AMD EPYC (Rome) CPUs. Consumer-grade CPUs may have to wait until December 2023 to get patched (See same Security Bulletin, "Target Dec 2023"). Please correct me if I'm wrong.

This is particularly painful for home-users and enthusiasts who may be running the hypervisor on consumer-grade hardware. I was able to confirm that the vulnerability is exploitable* on an AX41 Server from Hetzner. I've seen Hetzner being mentioned quite a lot in the forums, so this likely affects a few folks using the cheaper Hetzner offerings to run their Hypervisors.

*Tested with a non-privileged user directly on the hypervisor. I was not able to exploit it from inside a VM with the PoC published by Google (yet). Haven't had time to try with an LXC Container

 

[hunti]

The mentioned fix in the first link doesn't work for me:

# wrmsr -a 0xc0011029 $(($(rdmsr -c 0xc0011029) | (1<<9)))
rdmsr: open: No such file or directory
-bash: | (1<<9): syntax error: operand expected (error token is "| (1<<9)")

Any idea why?

Also as i see in kernel 6.4.6 there is already some code to automaticaly set the chicken bit if the microcode isn't fixed yet: https://git.kernel.org/pub/scm/linu...y&id=9b8bb5c4e25678af895dc9dd4a1e82b2f948cacc

 

[reflect]

The mentioned fix in the first link doesn't work for me:

# wrmsr -a 0xc0011029 $(($(rdmsr -c 0xc0011029) | (1<<9)))
rdmsr: open: No such file or directory
-bash: | (1<<9): syntax error: operand expected (error token is "| (1<<9)")

Any idea why?

Also as i see in kernel 6.4.6 there is already some code to automaticaly set the chicken bit if the microcode isn't fixed yet: https://git.kernel.org/pub/scm/linu...y&id=9b8bb5c4e25678af895dc9dd4a1e82b2f948cacc

Can confirm your observation, got the same error when trying to apply the workaround:

apt install msr-tools
modprobe msr
wrmsr -a 0xc0011029 $(($(rdmsr -c 0xc0011029) | (1<<9)))

Thanks for the link to the commit, wasn't aware of that one.

 

[hunti]

Can confirm your observation, got the same error when trying to apply the workaround:

apt install msr-tools
modprobe msr
wrmsr -a 0xc0011029 $(($(rdmsr -c 0xc0011029) | (1<<9)))

Thanks for the link to the commit, wasn't aware of that one.

Thanks, the modprobe fixed my problem.

 

[harmonyp]

I have Debian 11 still with Proxmox 7 what exact commands do I need to run?

 

[t.lamprecht]

As written other where, Debian migrated the amd64-microcode into bookworm and bullseye security repo overnight, so as long as you have that repo active either an upgrade, or a new installation should pull in the version with the fix for Zenbleed, namely: "3.20230719.1"

So ensure you got the security repo added, i.e., that one of your sources..list files got an entry like:

• for Proxmox VE 8.x (based on Debian Bookworm):

  deb http://security.debian.org bookworm-security main contrib non-free-firmware

• for Proxmox VE 7.x (based on Debian Bullseye):

  deb http://security.debian.org bullseye-security main contrib non-free

And then use:

apt update
apt install  amd64-microcode

(Which act as upgrade for that specific package too if already installed).

Then reboot.

Migration logs:
https://tracker.debian.org/news/144...202307191deb12u1-source-into-stable-security/
https://tracker.debian.org/news/144...deb11u1-source-amd64-into-oldstable-security/

FYI: a newer kernel with a workaround is underway, currently in the pvetest repo, but the microcode update is the better fix and has less performance impact, so should be always installed to avoid any performance regression (new kernel checks if new enough microcode package is installed on affected CPUs, otherwise it disables some CPU features as stop gap).

 

[hunti]

The microcode update only good for you if you have Epyc Rome processor. If you have any other CPU with ZEN 2, then you have to run this to install msr tools:

apt install msr-tools

Then after every boot (or now, without reboot):

modprobe msr
wrmsr -a 0xc0011029 $(($(rdmsr -c 0xc0011029) | (1<<9)))

Of course, you should also install the microcode, in a few months there will be a fix from AMD for the other Zen 2, not only for the EPYC CPU's.

 

[harmonyp]

How can I easily test this has been patched correctly? amd64-microcode installed

 

[hlindqvist]

How can I easily test this has been patched correctly? amd64-microcode installed

I think you can simply check /proc/cpuinfo and make sure it matches the new version 0x0830107A (for EPYC Rome) as per https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7008.html

(The microcode is only available for EPYC Rome so far)

 

[harmonyp]

I think you can simply check /proc/cpuinfo and make sure it matches the new version 0x0830107A (for EPYC Rome) as per https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7008.html

(The microcode is only available for EPYC Rome so far)

VM must be rebooted too? It was still showing the old code with live migration back until I rebooted the VM, or is this optional

 

[reflect]

How can I easily test this has been patched correctly? amd64-microcode installed

You could also run the PoC and see if the CPU still "bleeds"

# download the PoC, the shady looking URL belongs to the
# security researcher who discovered the vuln
# (see: https://lock.cmpxchg8b.com/zenbleed.html)
wget https://lock.cmpxchg8b.com/files/zenbleed-v5.tar.gz

# unpack the tarball
tar -xf zenbleed-v5.tar.gz

# change into unpacked directory
cd zenbleed/

# install packages required to build the PoC (debian)
apt install make gcc nasm build-essential

# compile
make

# run
./zenbleed

 

[harmonyp]

You could also run the PoC and see if the CPU still "bleeds"

# download the PoC, the shady looking URL belongs to the
# security researcher who discovered the vuln
# (see: https://lock.cmpxchg8b.com/zenbleed.html)
wget https://lock.cmpxchg8b.com/files/zenbleed-v5.tar.gz

# unpack the tarball
tar -xf zenbleed-v5.tar.gz

# change into unpacked directory
cd zenbleed/

# install packages required to build the PoC (debian)
apt install make gcc nasm

# compile
make

# run
./zenbleed

It's running with or without amd64-microcode, how do I see if it "bleeds"?

 

[reflect]

It's running with or without amd64-microcode, how do I see if it "bleeds"?

It should be fairly obvious if it does, it prints a bunch of strings straight out of your CPU registers. See the gif from the researchers blog post, it looks something like that. If the output just says "Spawning N Threads...", then prints a line for each CPU Core and stops printing anything, you might be fine. EDIT: If you run the PoC on an idle server, poke it a bit by running a bunch of other stuff while running the PoC, if the CPU got nothing to do it won't have much data to leak

Please note that I'm no expert in that particular vulnerability. It may not necessarily mean that you are not affected if the PoC doesn't print anything, please rather use it as a mean to confirm that you are in fact affected and then verify your workaround holds up by running it again. If your CPU model is listed as affected and you are on an unpatched system the safest bet is to assume you are affected even if you can't verify with the PoC.

I can confirm that running this workaround on an AX41 from Hetzner (Ryzen 3600) stops the PoC from printing data.

 

[robertut]

Hah....

Current Microsoft Xbox consoles are also likely affected, as they also have Zen 2 (Custom AMD 8-core Zen 2) CPUs inside:
- Xbox Series X: 3.8 GHz, 3.6 GHz with SMT
- Xbox Series S: 3.6 GHz, 3.4 GHz with SMT

Wonder when will M$ release a patch for these...

 

[t.lamprecht]

I can confirm that running this workaround on an AX41 from Hetzner (Ryzen 3600) stops the PoC from printing data.

Yes, as it's setting the chicken bit, like the new kernel does (if CPU is affected and microcode too old) and like recommended by the original researcher:
https://lock.cmpxchg8b.com/zenbleed.html#solution

The difference between this and the microcode update is that the microcode update has less performance penality, and thus is the better fix for the long term.

 

[Ramalama]

Hah....

Current Microsoft Xbox consoles are also likely affected, as they also have Zen 2 (Custom AMD 8-core Zen 2) CPUs inside:
- Xbox Series X: 3.8 GHz, 3.6 GHz with SMT
- Xbox Series S: 3.6 GHz, 3.4 GHz with SMT

Wonder when will M$ release a patch for these...

Funny when people start to panic.
For what is it necessary on an xbox?

Otherwise it's like always, the vulnerability needs to be executed by either the user or if you're a cloud provider that allow users host their vm/containers or whatever.
Normal homelab people that use their servers for themselves or family, which doesn't execute some code/ransomware or whatever, aren't affected.
Or can easily wait till December.

Epyc Servers which have already an Microcode update, for enterprise segments, which need a secure environment because they allow users to run code in their vm's or for whatever else reason, are fixed.

So basically only homelabbers are affected with their Ryzen cpus. So i wouldn't make a big deal out of it.
Since no one should anyway execute or run some crap.

Cheers

 

[reflect]

Funny when people start to panic.
For what is it necessary on an xbox?

Otherwise it's like always, the vulnerability needs to be executed by either the user or if you're a cloud provider that allow users host their vm/containers or whatever.
Normal homelab people that use their servers for themselves or family, which doesn't execute some code/ransomware or whatever, aren't affected.
Or can easily wait till December.

Epyc Servers which have already an Microcode update, for enterprise segments, which need a secure environment because they allow users to run code in their vm's or for whatever else reason, are fixed.

So basically only homelabbers are affected with their Ryzen cpus. So i wouldn't make a big deal out of it.
Since no one should anyway execute or run some crap.

Cheers

There is a reason this CVE doesn't have a particularly high score. That being said, I am slightly more worried about consumer devices using Zen2 where the potential for supply-chain attacks is larger (think developer notebooks, tech-savvy people that occasionally install random tools from the internet, etc). Actual risk depends on every individuals threat model, but I for one wouldn't feel particularly safe unlocking my password-manager or use my encryption/signature keys on a common computer with Zen2 as long as it isn't patched.

I want to keep an eye on the claim made by Cloudflare that this vulnerability is exploitable through the browser via Javascript, but they made no effort backing up that claim so I'm not too worried about it being remotely exploitable right now.

[...] The attack can even be carried out remotely through JavaScript on a website, meaning that the attacker need not have physical access to the computer or server.

I agree though, something like an Xbox where you don't install anything out of the ordinary has quite a low risk of exploitation IMO.

 

[Ramalama]

If it's indeed browser Javascript executable, that would be indeed a whole different story.