Okay, I’ve been reading the coverage of this and it seems like there is a lot of misconception going around especially in the comment sections of the various news articles. And then those comments sometimes get picked up and put into other news articles etc…

First things first, check out the blog post from the guy who discovered the bug, Travis Ormandy https://lock.cmpxchg8b.com/zenbleed.html It also looks like there was a timeline in the readme of the github repo from Travis

Timeline

2023-05-09 A component of our CPU validation pipeline generates an anomalous result.

2023-05-12 We successfully isolate and reproduce the issue. Investigation continues.

2023-05-14 We are now aware of the scope and severity of the issue.

2023-05-15 We draft a brief status report and share our findings with AMD PSIRT.

2023-05-17 AMD acknowledge our report and confirm they can reproduce the issue.

2023-05-17 We complete development of a reliable PoC and share it with AMD.

2023-05-19 We begin to notify major kernel and hypervisor vendors.

2023-05-23 We receive a beta microcode update for Rome from AMD.

2023-05-24 We confirm the update fixes the issue and notify AMD.

2023-05-30 AMD inform us they have sent a SN (security notice) to partners.

2023-06-12 Meeting with AMD to discuss status and details.

2023-07-20 AMD unexpectedly publish patches, earlier than an agreed embargo date.

2023-07-21 As the fix is now public, we propose privately notifying major distributions that they should begin preparing updated firmware packages.

2023-07-24 Public disclosure.

It looks like a microcode fix is already in place for the most affected security scenario which is datacenters running virtual machines on EPYC Rome generation server CPUs, where the danger is a malicious user leaking data from the cpu registers holding another user’s data. The danger to individuals running zen 2 CPUs in their own personal computers or in PS5/Xbox Series X/S and Steam Decks or other handhelds is a bit more nebulous.

There has been speculation that it might be possible to use this exploit on javascript in a browser. But I can’t find any concrete evidence that this has been worked out yet. The exploit from Travis is written in C and assembly and requires some specific timing to get the misprediction to occur reliably and even then there is no way to target specific processes. the exploit just offers a falsely available half a register as “free to use” another process requests register space and writes something to the “free to use” register before the branch misprediction resolves and calls back the register ownership and the malicious process reads what was left in the half a register. What ends up in that register could be a password or cryptographic key, or it could be a chunk of HTML or a UUID, or who knows what. So what you have is a box that spits out a bunch of keys, key like looking things, and blobs of malformed metal, and doesn’t tell you explicitly which is which or point you at the locks the keys go to.

This is much easier to get the timing reliably right when executing a bare binary. But when you are running javascript in a browser, you don’t get as fine grained control over the host processor and the timing. I won’t rule it out completely. But like I said, I have yet to see it be fully demonstrated. Give it a week, maybe someone will have figured it out. If someone does get a proof of concept running in javascript, then disable automatic javascript execution in your browser, or do as Travis outlined in his blog post and learn how to flip the chicken bit while you wait for microcode to filter down through your OS updates or your motherboard vendor to issue a Bios patch.

Another thing to keep in mind, the largest SIMD register on Zen2 is a 256bit register or 32 Bytes/characters. This exploit works by offering a half a register for unsuspecting processes to write data to, meaning 16 bytes/characters of data at a time. Please use passwords longer than 16 characters.