[sounds]

Huh. The very first line seems pretty clear:

   > If you remove the first word from the string "hello world", what should
   > the result be? This is the story of how we discovered that the answer
   > could be your root password!

Can you please expand on your question?

[bananapub]

I assume they meant "what does this do in normal vulnerability discussion terms", I don't know why tavis didn't just say "arbitrary memory read across processes" or whatever.

[ItsTotallyOn]

does it require physical access to the machine?

[kristopolous]

Beyond what everyone else said, these types of exploits can break out of VMs. Unless I'm misreading it you could log into your $5 linode/digitalocean/aws machine and start reading other people's data on the host machine.

There's tons of million dollar/month businesses on ~$20/month accounts on shared machines.

[sounds]

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

[pests]

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.

[0xbadcafebee]

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.

[KomoD]

I'll take this as bullshit until there's a POC

[Sohcahtoa82]

PoC || GTFO

[sounds]

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.

[LtdJorge]

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.

[saurik]

I would like to think that the likelihood of being able to find a juicy target using one of these specific CPUs and who would have explicitly not updated their microcode for this exploit is much much much higher going after end users on the web than by attacking organized VPS providers.

[pests]

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

[Y_Y]

Not even an xor? Harsh.

[mike_hock]

|| short-circuits.

[kzrdude]

Cloudflare blog also mentions javascript https://blog.cloudflare.com/zenbleed-vulnerability/

[loeg]

Might just be parroting the claim from this thread, though.

[Mahn]

I would think that Cloudflare is reputable enough that they would not state that claim without at least having some knowledge about it.

[loeg]

They have since rewritten that sentence from:

> The attack can even be carried out remotely through JavaScript on a website, meaning that the attacker need not have physical access to the computer or server.

https://web.archive.org/web/20230725020052/https://blog.clou...

To:

> Currently the attack can only be executed by an attacker with an ability to execute native code on the affected machine. While there might be a possibility to execute this attack via the browser on the remote machine it hasn’t been yet demonstrated.

https://web.archive.org/web/20230726204030/https://blog.clou...

I think I am vindicated -- they did just make that up, likely from the claim posted here.

[crtasm]

Might you post a screen recording?

[CyberDildonics]

Might you explain how that would prove anything?

[heywhatupboys]

effort to lie on a text comment << effort to lie with a video

[evandale]

We are on a tech site with highly intelligent individuals who have been programming computers since we've been in diapers.

If you don't believe the text then how would you believe the video? Anything can be done in devtools beforehand and I can think of a million different ways to fake the video.

Personally, if I didn't trust the text then an easily faked video wouldn't placate me either.

[CyberDildonics]

Might you think that source code would be much better proof and easier to send out?

[_flux]

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

[xmodem]

No, only the ability to execute arbitrary code in an unprivileged context. Would probably have to be arbitrary x86_64 instructions - Javascript wouldn't cut it for this one.

[kzrdude]

No, it requires unprivileged arbitrary code execution