Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zenbleed

lock.cmpxchg8b.com

Post reply on HN
Print view View original

191–200 of 378 posts

Re: Zenbleed

#191

Post by msla »

phendrenad2 wrote: post #101
0xbadcafebee wrote: post #44

This is super cool. This exploit will be one of the canonical examples that just running something in a VM does not mean it's safe. We've always known about VM breakout, but this is a no-breakout massive exploit that is simple to execute and gives big payoffs. Remember: just because this one bug gets fixed in microcode doesn't mean there's not another one of these waiting to be discovered. Many (most?) 0-days are kno…

The problem is, VMs aren't really "Virtual Machines" anymore. You're not parsing opcodes in a big switch statement, you're running instructions on the actual CPU, with a few hardware flags that the CPU says will guarantee no data or instruction overlap. It promises! But that's a hard promise to make in reality.

This is because VM means two different things and has for a long time:

IBM's VM was and is a hypervisor. It dates to the mid 1960s, in the form of CP-40, and it didn't run opcodes in software, but in hardware.

https://en.wikipedia.org/wiki/IBM_CP-40

p-code machines, which interpret bytecode, date back almost as far, such as the O-code machine for BCPL.

https://en.wikipedia.org/wiki/BCPL

Getting people to distinguish between these concepts is probably a lost cause.

Re: Zenbleed

#192

Post by dTP90pN »

> AMD have released an microcode update for affected processors.

I don't think that is correct. AMD has released a microcode update[0] for family 17h models 0x31 and 0xa0, which corresponds to Rome, Castle Peak and Mendocino as per WikiChip [1].

So far, there seems to be no microcode update for Renoir, Grey Hawk, Lucienne, Matisse and Van Gogh. Fortunately, the newly released kernels can and do simply set the chicken bit for those. [2]

[0] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...

[1] https://en.wikichip.org/wiki/amd/cpuid#Family_23_.2817h.29

[2] https://github.com/torvalds/linux/commit/522b1d69219d8f08317...

Re: Zenbleed

#193

Post by LtdJorge »

This is both as cool as it is scary. I managed to "exfiltrate" pieces of my Bitwarden password (could easily be reconstructed), ssh login password, and bank credentials in a minute of running from a 10MB sample.

Re: Zenbleed

#194

Post by kludge41 »

eric__cartman wrote: post #59

This is incredibly scary. On my Zen 2 box (Ryzen 3600) logging the output of the exploit running as an unprivileged user while copying and pasting a string into a text editor in the background (I used Kate), resulted in pieces of the string being logged into the output of zenbleed. And this is after a few seconds of runtime mind you, not even a full minute. Thankfully the exploit is highly dependent on a specific asm…

How do you build the POC? I get "No such file or directory" and error 127 on Ubuntu.

Re: Zenbleed

#195

Post by taviso »

href wrote: post #170

Can anyone explain the `wrmsr -a 0xc0011029 $(($(rdmsr -c 0xc0011029) | (1<<9)))`? It seems to help on my system, but I don't understand what it does, and I don't know how to unset it.

An msr is a "model specific register", a chicken bit can configure cpu features.

They don't persist across a reboot, so you can't break anything. You can undo what you just did without a reboot, just use `... & ~(1 << 9)` instead (unset the bit instead of set it).

Re: Zenbleed

#196

Post by eric__cartman »

kludge41 wrote: post #194
eric__cartman wrote: post #59

This is incredibly scary. On my Zen 2 box (Ryzen 3600) logging the output of the exploit running as an unprivileged user while copying and pasting a string into a text editor in the background (I used Kate), resulted in pieces of the string being logged into the output of zenbleed. And this is after a few seconds of runtime mind you, not even a full minute. Thankfully the exploit is highly dependent on a specific asm…

How do you build the POC? I get "No such file or directory" and error 127 on Ubuntu.

I had to run make on the uncompressed folder. Perhaps the build-essential package doesn't come with NASM in Ubuntu? I'll need a bit more info on the error if you want me to try and help you :)

Re: Zenbleed

#197

Post by dTP90pN »

dTP90pN wrote: post #192

> AMD have released an microcode update for affected processors. I don't think that is correct. AMD has released a microcode update[0] for family 17h models 0x31 and 0xa0, which corresponds to Rome, Castle Peak and Mendocino as per WikiChip [1]. So far, there seems to be no microcode update for Renoir, Grey Hawk, Lucienne, Matisse and Van Gogh. Fortunately, the newly released kernels can and do simply set the chicken…

More details:

`good_revs` as per the kernel: https://github.com/torvalds/linux/commit/522b1d69219d8f08317...

Currently published revs ("Patch") (git HEAD):

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...

As of this writing, only two of the five `good_rev`s have been published.

Re: Zenbleed

#198

Post by wolf550e »

yakubin wrote: post #108
taviso wrote: post #52

Earlier quoted context omitted.

welp, that's unfortunate indeed. It's a single-core 128 MB VPS, which seemed fine for my boring static html articles. I guess I underestimated the interest.

FWIW, enabling gzip/zstd compression in your HTTP server could help.

Only with something like mod_asis (https://httpd.apache.org/docs/2.4/mod/mod_asis.html) to serve already compressed content. Actually running zlib on every request will only make it worse.

Re: Zenbleed

#199

Post by ls612 »

formerly_proven wrote: post #76
ls612 wrote: post #36

Earlier quoted context omitted.

My new computer takes a while to POST (z690 with ddr5 smh) so it’s basically been continuously either on or in sleep since I built it 18 months ago and I’ve had an unexpected shutdown due to power loss once in that time according to the Event log. I think the risk of losing power while flashing the bios is very small in real life unless you are stuck in a place with third world electricity infrastructure.

If POST takes a long time it’s often memory training, backing off on the timings just slightly might make it go a lot quicker. Bios updates also often twiddle knobs in this area.

It isn’t this, it takes about a minute to train after a bios update or when I enable XMP but never trains after that. It just takes like 20-30 seconds to get all the way to the bios splash screen and only 5 seconds to return from sleep so I just use sleep instead of turning it off. Then the only time I need to wait through a boot is for windows updates.

Re: Zenbleed

#200

Post by wolf550e »

codedokode wrote: post #109

I don't understand how a microcode update could fix this. I assume microcode is used for slow operations like triginometric functions, and doesn't affect how registers are allocated or renamed. Or does the update simply disables some optimizations using "chicken bits"? And by the way, is there a list of such bits?

The designers leave themselves an ability to override any instruction using the microcode so they can patch any instruction. They don't use the microcode only to implement complex instructions that require loops.
Post reply on HN