It's worth noting that the FSF consider that supporting microcode updates makes software "un-free". This is a great example of what an inordinately stupid and harmful position that is.
Zenbleed
261–270 of 378 posts
Re: Zenbleed
#262To me this is the buried lede:
> It was challenging to get the details right, but I used this to teach my fuzzer to find interesting instruction sequences. This allowed me to discover features like merge optimization automatically, without any input from me!
What happens when AI can start fuzzing software? Seems like a golden opportunity for opsec folks.
Re: Zenbleed
#263Earlier quoted context omitted.
Yup! I worked at a few companies that would co-mingle Internet facing/DMZ VMs with internal VMs. When pointing this out and recommending we should airgap these VMs to it's own dedicated hypervisor it always fell on deaf ears. Jokes on them I guess.
I'm pretty sure AWS/Azure/GCP don’t assign separate boxes to every customer, and somehow they’re fine.
Not sure if they're actually fine, some researchers have exploited this vulnerability on AWS instances that use affected EPYC CPUs: https://twitter.com/0xdabbad00/status/1683581484337348608
Re: Zenbleed
#264I 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?
Everything a modern CPU runs is microcode. There are a few x86 instructions that translate to a single microcode instruction, but most are translated to several.
this hasn't been the case since the 486
Re: Zenbleed
#265This 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…
You can rent one of the Atom Kimsufi boxes (N2800) to experience first hand a cpu with no speculative execution. The performance is dire, but at least it hasn’t gotten worse over the years - they are immune to just about everything
Re: Zenbleed
#266Earlier quoted context omitted.
Yup! I worked at a few companies that would co-mingle Internet facing/DMZ VMs with internal VMs. When pointing this out and recommending we should airgap these VMs to it's own dedicated hypervisor it always fell on deaf ears. Jokes on them I guess.
I'm pretty sure AWS/Azure/GCP don’t assign separate boxes to every customer, and somehow they’re fine.
Just running on a separate core would avoid this bug.
Re: Zenbleed
#267Earlier 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.
As an aside, I'd be curious to now how your VPS failed. Memory? Bandwidth?
I'm not really sure, cpu and bandwidth utilization were fine. Memory usage was high, but not oom high. It continued serving over http just fine, perhaps there was some automated rate limiting by my provider.
I'll have to debug when things cool down.
I'm aware 128M is ludicrous in 2023... "a fun challenge", I thought to myself. I can be a dummy.
Re: Zenbleed
#268Anybody know how to disable the chicken bit on Windows?
They're not planning to fix this until fucking December...
Re: Zenbleed
#269This 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…
I’m quite surprised there hasn’t been a cloud apocalypse yet where something just runs rampant through AWS or something.
Re: Zenbleed
#270This 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…
> Thankfully the exploit is highly dependent on a specific asm routine so exploiting it from JS or WASM in a browser should be extremely difficult.
I assume that once/if a method is found it will be applicable broadly though. At the same time, hopefully software patches in V8 and SpiderMonkey will be able to mitigate this further and sooner.
But a JS exploit would require some way to exfiltrate data and presumably doing that would be quite difficult to hide entirely.