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

61–70 of 378 posts

Re: Zenbleed

#61

Post by timmaxw »

ItsTotallyOn wrote: post #23

What does this allow the attacker to do? Steal data? The post isnt very clear.

It allows the attacker to eavesdrop on the data going through operations like strcmp(), memcpy(), and strlen(). (These are the standard functions in C for working with strings; and many higher-level languages use them under the hood.) It works on any function that uses the XMM/YMM/ZMM registers.

It's stochastic; the attacker randomly gets data from whatever happens to be using the XMM/YMM/ZMM registers at the time. So if the attacker could eavesdrop in the background constantly, they might eventually see a password. Or they might be able to trigger some system code that processes your password, then eavesdrop for the next few milliseconds.

The attacker needs to run code on your machine. Unclear if running code in a web browser is sufficient or not. It requires an unusual sequence of machine instructions, which isn't necessarily possible in JS/WASM, but 'sounds' says they did it: https://news.ycombinator.com/item?id=36849767

Re: Zenbleed

#62

Post by hammock »

mrpippy wrote: post #11

It feels like not-a-coincidence that OpenBSD added AMD microcode loading in the last 3 days. https://news.ycombinator.com/item?id=36838511

Explain that like I’m 5?

Re: Zenbleed

#63

Post by _flux »

sounds wrote: post #38
ItsTotallyOn wrote: post #33

Earlier quoted context omitted.

does it require physical access to the machine?

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

What javascript was that, or did you create your own? I did not find any from this post.

Re: Zenbleed

#64

Post by laverya »

hammock wrote: post #62
mrpippy wrote: post #11

It feels like not-a-coincidence that OpenBSD added AMD microcode loading in the last 3 days. https://news.ycombinator.com/item?id=36838511

Explain that like I’m 5?

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

Re: Zenbleed

#66

Post by [deleted] »

jedberg wrote: post #48
ksec wrote: post #40

Earlier quoted context omitted.

It is a simple static HTML page, how is it possible in 2023 a static site could be hugged to death. In most cases HN traffic barely hits 100 page view per second.

It's a security writeup so it's probably run by a security expert who is not an expert at running high traffic websites. Most likely there is something on the page that causes a database hit. Possibly the page content itself.

[deleted]

Re: Zenbleed

#67

Post by darkclouds »

Nice catch!

> If you can’t apply the update for some reason, there is a software workaround: you can set the chicken bit DE_CFG[9].

It reminds me of the compiler switches which can alter the way code at different levels (global, procedure, routine) can access variables declared at different levels and the change in scope that ensues.

Maybe some of this HW caching should be left to the coders.

Re: Zenbleed

#69

Post by account42 »

taviso wrote: post #52
ksec wrote: post #40

Earlier quoted context omitted.

It is a simple static HTML page, how is it possible in 2023 a static site could be hugged to death. In most cases HN traffic barely hits 100 page view per second.

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.

Interesting, do you mind sharing what software you use to serve the static html and what kind of traffic its getting.

Re: Zenbleed

#70

Post by cmrdporcupine »

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…

In the end, I'm thinking most of these are related to branch prediction?

It strikes me that it's either that branch prediction is so inherently complex enough it's always going to be vulnerable to this and/or it just so defies the way most of us intuitively think about code paths / instruction execution that it's hard to conceive of the edge cases until too late?

At what point does the complexity of CPU architectures become so difficult to reason about that we just accept the performance penalty of keeping it simpler?

Post reply on HN