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

181–190 of 378 posts

Re: Zenbleed

#181

Post by toast0 »

zamadatix wrote: post #171
jeroenhd wrote: post #161

Earlier quoted context omitted.

Not only do people do this, it's generally how VPS providers work. Most machines barely use the CPU most of the time (web servers etc.) so reserving a full CPU core for a VPS is horribly inefficient. It doesn't matter anyway, because SMT isn't relevant for this particular bug. With SMT allowing twice the cores on a CPU for most workloads, disabling it would double the cost for most providers! There are VPS providers…

SMT is relevant in the VM case of this bug because it determines whether this bug is restricted to data outside the VM or not. Providers usually won't disable SMT completely, they'd run a scheduler which only allows 1 VM to use both SMT threads of a core. Ultra cheap VPS providers may still find that not worth the pennies though as if you sell a majority of single core VPS then the majority of your SMT threads are st…

> Fully dedicated cores aren't necessarily required because in the timesliced case the registers are unloaded and reloaded when different VMs are shuffled on and off the core. That said, they definitely prevent the cross-vm-data-leak case of this bug.

Registers are unloaded and reloaded when different processes / threads are scheduled within a running VM too. That should protect the register contents, but because of this issue, it doesn't, so I don't see why it would if it's a hypervisor switching VMs instead of an OS switching processes. If you're running a vulnerable processor on a vulnerable microcode, it seems like you can potentially read things put into the vulnerable registers by anything else running on the same physical core, regardless of context.

Re: Zenbleed

#182

Post by wolf550e »

jahsome wrote: post #125
laverya wrote: post #64

Earlier quoted context omitted.

The patch for this exploit is to load AMD's updated microcode.

I'm not sure five year olds know what microcode is. I'm 35, been in tech nearly 20 years and don't recall having heard that specific term before today.

A Grandchild's Guide to Using Grandpa's Computer a.k.a. "If Dr. Zeuss were a Technical Writer" was written in 1994 and mentions microcode.

Microcode updates are always discussed when talking about microarchitectural security vulnerabilities (and other scary CPU errata like https://lkml.org/lkml/2023/3/8/976).

Microcode is always mentioned when discussing CPU design evolution.

Re: Zenbleed

#183

Post by LtdJorge »

sounds wrote: post #160
Sohcahtoa82 wrote: post #93

Earlier quoted context omitted.

PoC || GTFO

OP here hadn't even bothered to read the article. That's the context of my reply. No PoCs going online so close to the disclosure, sorry.

What? The researcher that found it and wrote the article already posted a PoC that can be used to farm data from VMs in any VPS provider.

Re: Zenbleed

#184

Post by loeg »

gavinhoward wrote: post #154
loeg wrote: post #149

Earlier quoted context omitted.

Essentially because memory mappings and RAM work at page granularity, rather than bytes. If a read from in-bounds in a page isn't going to fault, a read later in the same page isn't going to fault either (even if it is past the end of the particular object). You can see this in glibc's implementation, which checks for crossing page boundaries: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86... (line ~68)

Ah, so that's why there is special code in Valgrind to handle glibc and friends!

I think capability-pointer machines like CHERI might need in-bounds-only variants of these functions, too.

Re: Zenbleed

#185

Post by stcredzero »

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…

this is a no-breakout massive exploit that is simple to execute and gives big payoffs

Wouldn't we be able to avoid the "big payoffs" of no-breakout exploits if we had specialized hardware handle the secrets?

Re: Zenbleed

#186

Post by pests »

sounds wrote: post #160
Sohcahtoa82 wrote: post #93

Earlier quoted context omitted.

PoC || GTFO

OP here hadn't even bothered to read the article. That's the context of my reply. No PoCs going online so close to the disclosure, sorry.

It's okay to admit you are wrong or don't have a working POC.

Re: Zenbleed

#187

Post by jahsome »

eindiran wrote: post #131
jahsome wrote: post #125

Earlier quoted context omitted.

I'm not sure five year olds know what microcode is. I'm 35, been in tech nearly 20 years and don't recall having heard that specific term before today.

The whole "explain like I'm 5" thing is ridiculous. A huge percentage of topics simply cannot be broken down to an average 5 year old in a way that makes the conversation worth having at all. The 5 year old has no context about why in recent years there has been a huge push towards running your own code on other people's computers using various isolation techniques, or why people are trying to exploit that. The 5 yea…

Sure, I can look it up (and I did) but this is a discussion section, so why not prompt a discussion by asking for a simple explanation?

Appreciate the link! I'm not OP but that's exactly what I was looking for.

Re: Zenbleed

#188

Post by 0xbadcafebee »

pests wrote: post #114
sounds wrote: post #38

Earlier quoted context omitted.

I was able to reproduce the vulnerability using javascript on a webpage. Therefore, no.

Why is everyone claiming this is impossible in JavaScript? If you have a POC you should post it so others can learn of the danger. You've even been quoted elsewhere in this thread about this topic.

Some people think you need "the ability to execute arbitrary code in an unprivileged context" to perform this exploit. Which is of course a false assumption. The bug class in this case is basically a user-after-free, for a function which keeps its state per-cpu-core, for a function that is (for almost all intents and purposes) unprivileged.

From the article:

  We now know that basic operations like strlen, memcpy and strcmp will use the vector registers - 
  so we can effectively spy on those operations happening anywhere on the system! It doesn’t matter
  if they’re happening in other virtual machines, sandboxes, containers, processes, whatever!
All you need to do is write some JavaScript that will "trigger something called the XMM Register Merge Optimization2, followed by a register rename and a mispredicted vzeroupper". It's up to the hacker to determine how to do this explicitly in JS, but it's theoretically possible by literally any application at any time on any operating system. Even if some language or interpreter claims to prevent it, it's possible to find an exploit in that particular language/interpreter/etc to get it to happen.

This is how exploit development works; if you can't go straight ahead, go sideways. I guarantee you that someone will find a way, if they haven't yet.

Re: Zenbleed

#189

Post by LtdJorge »

vladvasiliu wrote: post #136
gabereiser wrote: post #98

Earlier quoted context omitted.

This. Not everyone is as quick as say Arch or Fedora in updating/patching. Please reach out to your maintainers of the distro you use.

Even Arch seems out of date as of 24 jul 2023 17:55 UTC. The latest amd firmware version is 20230625.

Gentoo already has it, however the latest ebuild is still masked, so one would need to put "sys-kernel/linux-firmware ~amd64" inside a file in /etc/portage/package.accept_keywords, or better yet, always run the git version, using * instead of ~amd64.

Apart from that, it's necessary to "sudo emaint sync -A && sudo emerge -av sys-kernel/linux-firmware", while checking that the correct files are included in the savedconfig file if using it. After that, rebuild the kernel or the initramfs and reboot.

Re: Zenbleed

#190

Post by javajosh »

FirmwareBurner wrote: post #156
darkwater wrote: post #148

Earlier quoted context omitted.

I think the interesting point here might be one could be able to extract some secret from memory of a PS5, like to break some kind of encryption

What valuable secrets do people have on their PS5/Xbox? You also need a way to deploy the malicious payload on those platforms which, due to their closed nature, is very difficult to do.

Oh, I can imagine lots of uses for a bevy of PS5's, assuming you can gain remote control. What do you do with a botnet? What do you do with a botnet with a pretty good GPU? What do you do with an always-on microphone in people's living rooms?
Post reply on HN