zenbleed AMD security bug

S

serpretetsky

2[H]4U
Joined
Dec 24, 2008
Messages
2,180
Zen2 based CPUs have a new bug discovered which seems pretty bad. Zenbleed.

https://arstechnica.com/information...ug-in-many-amd-cpus-could-take-months-to-fix/
The bad news is that the exploit doesn't require physical hardware access and can be triggered by loading JavaScript on a malicious website.
Click to expand...

Ouch. list of cpus affected taken from ARStechnica
1690319349234.png
 
Last edited:
so my 5800X is safe!

and for the affected CPU's the fixes won't be available until Oct- Dec??...long wait
 
Medium severity security bug - CHECK
Potential disclosure of sensitive data - CHECK
Ease of attack - CHECK
Vulnerability through remote access - CHECK
Proof of concept code - CHECK
Reliance on updates from vendor through motherboard manufacturers via BIOS update - UH OH
Timing for mitigation December'23 - WTF

I've just about had it with my X570 rig and all the stability and security issues over the years. While others undoubtedly have had better experiences, I am about ready to write AMD off.
 
Mr Evil said:
If I'm reading AMD's own page about this right, the long delay is only to get the fix into BIOSes. The fix is available right now as a microcode update, which has already been added to Linux. I don't know about Windows though.
Click to expand...
uOpt said:
Fixed microcode has already been pushed into the Linux kernel:
https://git.kernel.org/pub/scm/linu.../?id=0bc3126c9cfa0b8c761483215c25382f831a7c6f
Click to expand...

So I ran the updates that came in today, and what do you know, there was a microcode update there.

Upon applying and rebooting I went from 0x0830104d to 0x0830107a which according to this article seems to be the correct one that addresses this vulnerability.

(this can also be confirmed in the kernel.org diff that uOpt posted:

Code: 
 Microcode patches in microcode_amd_fam17h.bin:
   Family=0x17 Model=0x08 Stepping=0x02: Patch=0x0800820d Length=3200 bytes
+  Family=0x17 Model=0x31 Stepping=0x00: Patch=0x0830107a Length=3200 bytes
+  Family=0x17 Model=0xa0 Stepping=0x00: Patch=0x08a00008 Length=3200 bytes
   Family=0x17 Model=0x01 Stepping=0x02: Patch=0x0800126e Length=3200 bytes
-  Family=0x17 Model=0x31 Stepping=0x00: Patch=0x08301072 Length=3200 bytes

 Microcode patches in microcode_amd_fam19h.bin:
   Family=0x19 Model=0x01 Stepping=0x01: Patch=0x0a0011d1 Length=5568 bytes

Thank you Linux Kernel team, Debian and Ubuntu for being on top of things once again.

As always when I read about these new vulnerabilities, the fix is already waiting for me in my update manager.
 
Zarathustra[H] said:
So I ran the updates that came in today, and what do you know, there was a microcode update there.

Upon applying and rebooting I went from 0x0830104d to 0x0830107a which according to this article seems to be the correct one that addresses this vulnerability.

(this can also be confirmed in the kernel.org diff that uOpt posted:

Code: 
 Microcode patches in microcode_amd_fam17h.bin:
   Family=0x17 Model=0x08 Stepping=0x02: Patch=0x0800820d Length=3200 bytes
+  Family=0x17 Model=0x31 Stepping=0x00: Patch=0x0830107a Length=3200 bytes
+  Family=0x17 Model=0xa0 Stepping=0x00: Patch=0x08a00008 Length=3200 bytes
   Family=0x17 Model=0x01 Stepping=0x02: Patch=0x0800126e Length=3200 bytes
-  Family=0x17 Model=0x31 Stepping=0x00: Patch=0x08301072 Length=3200 bytes

 Microcode patches in microcode_amd_fam19h.bin:
   Family=0x19 Model=0x01 Stepping=0x01: Patch=0x0a0011d1 Length=5568 bytes

Thank you Linux Kernel team, Debian and Ubuntu for being on top of things once again.

As always when I read about these new vulnerabilities, the fix is already waiting for me in my update manager.
Click to expand...
And Palo Alto has already updated their vulnerabilities list to watch for it.
 
night_2004 said:
Medium severity security bug - CHECK
Potential disclosure of sensitive data - CHECK
Ease of attack - CHECK
Vulnerability through remote access - CHECK
Proof of concept code - CHECK
Reliance on updates from vendor through motherboard manufacturers via BIOS update - UH OH
Timing for mitigation December'23 - WTF

I've just about had it with my X570 rig and all the stability and security issues over the years. While others undoubtedly have had better experiences, I am about ready to write AMD off.
Click to expand...
Meanwhile my X570 build has been my most stable in recent memory. It has been rock-solid and much better than the Intel board it replaced. Though that could just be a Gigabyte (X570) vs Asrock (Intel) difference. Anyway, anecdotal evidence is just that and YMMV ;)

Not a fanboy and both sides have their vulnerabilities that crop up. That said the delay is ridiculous, especially with this being exploitable remotely. I'm hoping Intel will get their act together and compete without being a space heater.
 
Thanks for the heads up on this - have some machines in production which will likely need to get this fix as soon as it comes out. Anyone happen to have word on a fix for Windows? I'm searching, but.....if you know it would help :)
 
Patton43 said:
Meanwhile my X570 build has been my most stable in recent memory. It has been rock-solid and much better than the Intel board it replaced. Though that could just be a Gigabyte (X570) vs Asrock (Intel) difference. Anyway, anecdotal evidence is just that and YMMV ;)

Not a fanboy and both sides have their vulnerabilities that crop up. That said the delay is ridiculous, especially with this being exploitable remotely. I'm hoping Intel will get their act together and compete without being a space heater.
Click to expand...
On my same x370, went from 1700 -> 3900x -> 5600x

Yay stable and woot not affected
 
Linux - lscpu tells me:
Vulnerabilities:
Itlb multihit: Not affected
L1tf: Not affected
Mds: Not affected
Meltdown: Not affected
Mmio stale data: Not affected
Retbleed: Mitigation; untrained return thunk; SMT enabled with STIBP protection
Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Spectre v2: Mitigation; Retpolines, IBPB conditional, STIBP always-on, RSB filling, PBRSB-eIBRS Not affected
Srbds: Not affected
Tsx async abort: Not affected

Alas, Zenbleed is not mentioned. Mint 21, updated today. R5 3600.
Oh well.
 
michalrz said:
Linux - lscpu tells me:
Vulnerabilities:
Itlb multihit: Not affected
L1tf: Not affected
Mds: Not affected
Meltdown: Not affected
Mmio stale data: Not affected
Retbleed: Mitigation; untrained return thunk; SMT enabled with STIBP protection
Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Spectre v2: Mitigation; Retpolines, IBPB conditional, STIBP always-on, RSB filling, PBRSB-eIBRS Not affected
Srbds: Not affected
Tsx async abort: Not affected

Alas, Zenbleed is not mentioned. Mint 21, updated today. R5 3600.
Oh well.
Click to expand...

Do a "dmesg |grep microcode" and look for the updated microcode to see if it is addressed.

In my Mint install I got the new microcode yesterday before this even hit the news.

A reboot may be required after the microcode package updates to make sure it is loaded. For my Threadrtipper, 0x0830107a was the microcode that addressed it.
 
michalrz said:
I think some of you guys are still confusing Javascript with Java.
If Javascript can attack the CPU, it's probably a browser issue.
Click to expand...
This!
This is why it is IMPERATIVE that scripts are NEVER allowed to run on their own from ANY website, period! Always have filtering in place before packets even reach your switch let alone machine NIC. Or you will be sorry. ;-)
 
michalrz said:
Linux - lscpu tells me:
Vulnerabilities:
Itlb multihit: Not affected
L1tf: Not affected
Mds: Not affected
Meltdown: Not affected
Mmio stale data: Not affected
Retbleed: Mitigation; untrained return thunk; SMT enabled with STIBP protection
Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Spectre v2: Mitigation; Retpolines, IBPB conditional, STIBP always-on, RSB filling, PBRSB-eIBRS Not affected
Srbds: Not affected
Tsx async abort: Not affected

Alas, Zenbleed is not mentioned. Mint 21, updated today. R5 3600.
Oh well.
Click to expand...

I think that only lists vulnerabilities that the actual kernel works around.

Zenbleed is not worked around by the running kernel, it is a microcode fix. Such a fix is distributed with the kernel, but it doesn't run in the kernel.
 
Zarathustra[H] said:
Do a "dmesg |grep microcode" and look for the updated microcode to see if it is addressed.

In my Mint install I got the new microcode yesterday before this even hit the news.

A reboot may be required after the microcode package updates to make sure it is loaded. For my Threadrtipper, 0x0830107a was the microcode that addressed it.
Click to expand...
Tanks! It spat out:
microcode: CPU0: patch_level=0x08701021
(same line for all logical CPUs)
microcode: Microcode Update Driver: v2.2.
That said, system updater says my crapbox is up to date, and I rebooted it after updating.

cpufrost said:
This!
This is why it is IMPERATIVE that scripts are NEVER allowed to run on their own from ANY website, period! Always have filtering in place before packets even reach your switch let alone machine NIC. Or you will be sorry. ;-)
Click to expand...
Actually, I meant something else - running scripts (Javascript) in your browser is fine, as long as your browser isn't compromised/out of date. A lot of things we take for granted online are Javascript-based, and the only scenario I can think of where I'd hard-disable JS would be some critical system that isn't supposed to be used as a surfing machine. That way, one can at least google some error or tutorial while minimizing the risk.

Now, Java applets in-browser are/used to be the Typhoid Mary of the Interwebs.
Some regular software is Java-based - I usually only have those installed if I absolutely need them, because constantly updating the runtime environment is a chore.

uOpt said:
I think that only lists vulnerabilities that the actual kernel works around.

Zenbleed is not worked around by the running kernel, it is a microcode fix. Such a fix is distributed with the kernel, but it doesn't run in the kernel.
Click to expand...
Thanks for the explanation, didn't know that!
 
blackmomba said:
brb uninstalling javascript
Click to expand...

Gideon said:
Unless you have a machine that still needs javascript, I am not sure it's that big of a deal. Hopefully for those affected the patches will roll out sooner then stated.
Click to expand...

michalrz said:
I think some of you guys are still confusing Javascript with Java.
If Javascript can attack the CPU, it's probably a browser issue.
Click to expand...
1) This is a Speculative execution bug. i doubt it's limited to JavaScript.

2) agreed with micharlz that some of you are confusing java with javascript or are being funny. JavaScript is what every browser executes by default.
 
Looks like they already have a fix out to datacenter customers which is where most of the damage could be done. Not too bad. Yeah the long delay to get the fix into BIOS updates sucks, but at the same time a lot of recent stability and performance issues from newer BIOS releases warrants that delay lol. Last thing AMD needs is more outrage from the average consumer to send everyone back to intel (again). The ironic thing is nothing is perfect, there will always be something for the masses to complain about :ROFLMAO:

I'd be more worried about attack vectors on mobile tbh. Need a specific app for everything and its bad
 
serpretetsky said:
1) This is a Speculative execution bug. i doubt it's limited to JavaScript.

2) agreed with micharlz that some of you are confusing java with javascript or are being funny. JavaScript is what every browser executes by default.
Click to expand...
I think the point was that because Javascript by default, is a trusted load from the Internet, that easy exploitation is possible.

Local exploitation, for sure, but anytime you can deliver remotely an exploit that runs by default, well, there ya go!!
 
cjcox said:
I think the point was that because Javascript by default, is a trusted load from the Internet, that easy exploitation is possible.

Local exploitation, for sure, but anytime you can deliver remotely an exploit that runs by default, well, there ya go!!
Click to expand...
Agreed. I'm just seeing posts that seem to imply that the language or the browser is at fault. Just want to make sure we're on the same page. The CPU is at fault.
 
night_2004 said:
Medium severity security bug - CHECK
Potential disclosure of sensitive data - CHECK
Ease of attack - CHECK
Vulnerability through remote access - CHECK
Proof of concept code - CHECK
Reliance on updates from vendor through motherboard manufacturers via BIOS update - UH OH
Timing for mitigation December'23 - WTF

I've just about had it with my X570 rig and all the stability and security issues over the years. While others undoubtedly have had better experiences, I am about ready to write AMD off.
Click to expand...

*Meltdown has entered the chat*
 
VoloxitySF said:
Looks like they already have a fix out to datacenter customers which is where most of the damage could be done. Not too bad. Yeah the long delay to get the fix into BIOS updates sucks, but at the same time a lot of recent stability and performance issues from newer BIOS releases warrants that delay lol. Last thing AMD needs is more outrage from the average consumer to send everyone back to intel (again). The ironic thing is nothing is perfect, there will always be something for the masses to complain about :ROFLMAO:

I'd be more worried about attack vectors on mobile tbh. Need a specific app for everything and its bad
Click to expand...

I'm pretty sure that Windows does the same thing as Linux - trasport microcode updates with the kernel. So that would mean a Windows update in the near future woud fix this for you.
 
serpretetsky said:
1) This is a Speculative execution bug. i doubt it's limited to JavaScript.
Click to expand...
As an SPA alt-web developer, I would concur. We have JavaScript alternatives now, such as WebAssembly that have their own VM-like environment to run in a browser. Given this is a hardware exploit, I assume they are just as vulnerable too. Nothing is safe. Every mainstream browser is probably affected.

The web just happens to currently be built on JavaScript. So of course it gets the most attention when exploits like this hit the clickbait channels. For those seriously suggesting disabling JavaScript: that is not an option. You'd cripple the vast majority of web sites. The user experience would range from not working to, at best, a circa 1997 web browsing experience. Not a sane solution.

I got a nice chuckle from those who seem to confuse Java with JavaScript. If we're being serious, they are not even remotely the same. Yet again proving how poorly the choice of naming JavaScript. I guess it still sounds better (more edgy?) than ECMAScript?
 
Absalom said:
I got a nice chuckle from those who seem to confuse Java with JavaScript. If we're being serious, they are not even remotely the same. Yet again proving how poorly the choice of naming JavaScript. I guess it still sounds better (more edgy?) than ECMAScript?
Click to expand...

Yeah, you can say that again.

Everyone outght to know that Java and JavaScript have absolutely nothing to do with eachother other than the stupidly chosen first four letters of the name.

Absalom said:
As an SPA alt-web developer, I would concur. We have JavaScript alternatives now, such as WebAssembly that have their own VM-like environment to run in a browser. Given this is a hardware exploit, I assume they are just as vulnerable too. Nothing is safe. Every mainstream browser is probably affected.
Click to expand...

This is why we need to change how we develop web apps. 100% of everything should be executed on the server side. The only thing that should be presented to the client should be static html. If you can't design your website to operate in this manner, it shouldn't be allowed to be published.

I'm all for breaking the entirety of the current internet and all existing protocols and recreating them with a zero trust security and privacy framework, where everything is encrypted, everything is anonymous, nothing can be tracked or collected, and nothing can be executed on client machines.

If that takes us back to 1997, so be it. You say that as if it is a bad thing. 1997 wasn't bad. I liked 1997. All the bad shit started happening in 2007. Since ~2007 the internet has turned into some zero privacy, free-for-all dystopian bullshit.

It's time we tear everything down and build it back up again with protocols that are specifically designed to ensure anonymity, privacy and security at all times.

And lets kill all things AI, all automation that defaults to "on", and all things cloud while we are at it. None of my devices should reach out over a network and interact with any other machine unless I explicitly tell them to. Automation is fine, but only if I choose enable it.

Kill all things autodiscovery except DHCP and layer2 stuff for switching. I don't want any of my machines to "discover" that a new device has been connected to my network. I want to install software manually, and point that software at an IP address I have configured. I need to always be the one in control of MY network and MY computer. Fuck things like Bonjour, Avahi and SSDP.

Make everything manual again, and require shipping ALL hardware and software in their least permissive state, requiring users to read and understand before enabling things, with a full disclosure of all things that are shared, written concisely in a way that all users can understand it. No one should ever be surprised by any of their devices sending shit over the network they hadn't intended. The default state of EVERYTHING should be: "I don't reach out to or respond to anything at all on the network, even only the LAN unless explicitly told to."

All devices should be local technology first, with an option to connect to the internet, not this always on and always listening dystopian nightmare.
 
Last edited:
Zarathustra[H] said:
This is why we need to change how we develop web apps. 100% of everything should be executed on the server side. The only thing that should be presented to the client should be static html. If you can't design your website to operate in this manner, it shouldn't be allowed to be published.

I'm all for breaking the entirety of the current internet and all existing protocols and recreating them with a zero trust security and privacy framework. where everything is encrypted, everything is anonymous, nothing can be tracked or collected, and nothing can be executed on client machines.

If that takes us back to 1997, so be it. You say that as if it is a bad thing. 1997 wasn't bad. All the bad shit started happening in 2007. Since ~2007 the internet has turned into some zero privacy, free-for-all dystopian bullshit.

it's time we tear everything down and build it back up again with protocols that are specifically designed to ensure anonymity, privacy and security at all times.
Click to expand...
While I agree that some things should never be left up the client, I don't agree with regressing back to server-side everything. Most SPA things handled exclusively client-side are trivial and have nothing to do with security. At worst, an exploit comes along and the user has a degraded experience until things gets patched. Plus the performance of doing everything server-side would ultimately suck. The user experience would degrade, etc. But when it comes to browser security, I wholeheartedly agree. Security should always be a server-side only thing.

I do share a web design philosophy that you should never trust the client especially when it comes to security. The client can always be reversed engineered no matter how clever you think you are with your design. You can still accomplish things in a dynamic way, you just have to be selective about what content the client can store locally.

A lot of current browser security issues are just due to complacency or developer laziness. Session cookie theft is a prime example of a modern exploit. There have been some recent movements such as Backend for Frontends which is nothing more than a design philosophy where the developer merely takes more ownership of securing their web api by ensuring sensitive data is absolutely never stored by the client.
 
From a security point of view, sites pulling in JS from everywhere, etc, makes things "difficult".

"I was on walmart.com...."

You mean, you were on the 10% that actually comes from walmart.com.
 
cjcox said:
From a security point of view, sites pulling in JS from everywhere, etc, makes things "difficult".

"I was on walmart.com...."

You mean, you were on the 10% that actually comes from walmart.com.
Click to expand...

I want to live in a world where I can reject all cookies, connect through a VPN, block everything on a website that does not originate from the same TLD and block all scripts and still have everything work perfectly.
 
Absalom said:
The web just happens to currently be built on JavaScript. So of course it gets the most attention when exploits like this hit the clickbait channels. For those seriously suggesting disabling JavaScript: that is not an option. You'd cripple the vast majority of web sites. The user experience would range from not working to, at best, a circa 1997 web browsing experience. Not a sane solution.
Click to expand...
Selective use of javascript is certainly possible. I use noscript with a small collection of servers permanently whitelisted and most of the time it just works like an ad blocker that also gets rid of some of the other extraneous stuff they add these days, sometimes I have to temporarily whitelist some servers for a site to work properly but even then I can usually leave the ad and tracking servers blocked and get a cleaner page.

It's not something I would expect most people to want to deal with but I think it gives me a cleaner web experience than can be achieved with ad blockers alone.
 
You must log in or register to reply here.
Back
Top