[ajross]

As described it's just a CPU crash exploit that requires local binary execution. Getting to a vulnerability would require understanding exactly how the corrupted microcode state works, and that seems extremely difficult outside of Intel.

So as described, this isn't a "valuable" bug.

[dgacmu]

It's not super-valuable yet, but it would keep you mount a really nasty DoS on cloud providers by triggering hard resets of the physical machines. Some people would probably pay for that, though it's obviously more interesting to push on privilege or exfiltration.

Particularly since the MCEs triggered could prevent an automatic reboot. Would depend what the hardware management system did - do machines presenting MCEs get pulled?

[toast0]

If I'm a cloud provider and somebody's workflow is hard resetting lots of my physical machines, I'm going to give them free access to single tenant machines at the very minimum. If they keep crashing the machines that only they run on, I guess that's ok.

[dgacmu]

You can exploit this from a single core shared instance.

So you go and find yourself a thousand cheap / free tier accounts, spin up an instance in a few regions each, and boom, you've taken out 10k physical hosts. And run it in a lambda at the same time, and see how well the security mechanisms identify and isolate you.

Causing a near simultaneous reboot of enough hosts is likely to take other parts of the infrastructure down.

[ajross]

I'm curious what part of this scheme involves "not ending up in jail"? Needless to say you can't do this without identifying yourself. To make this an exploitable DoS attack you need to be able to run arbitrary binaries on a few thousand cloud hosts that you didn't lease yourself.

[mschuster91]

> I'm curious what part of this scheme involves "not ending up in jail"? Needless to say you can't do this without identifying yourself.

Stolen credit cards are a dime a dozen, and nation state actors can just use their domestic banks or agents in the banks of other countries in a pinch to deflect blame or lay false trails.

If I were Russia or China, I'd invest a lot of money into researching all kinds of avenues on how to take out the large three public cloud providers if need be: take out AWS, Google, Microsoft and on the CDN side Cloudflare and Akamai and suddenly the entire Western economy grinds to a halt.

The only ones who will not be affected are the US government cloud services in AWS, as this runs separate from other AWS regions - that is, unless the attacker gets access to credentials that allow them executions on the GovCloud regions...

[ajross]

> If I were Russia or China, I'd invest a lot of money into researching all kinds of avenues on how to take out the large three public cloud providers

This subthread started with "is this issue a valuable exploit". Needless to say, if you need to invoke superpower-scale cyber warfare to find an application, the answer is "no". Russia and China have plenty of options to "take out" western infrastructure if they're willing to blow things up[1] at that scale.

[1] Figuratively and literally

[vbezhenar]

If clouds use shared servers to run their management workloads and if very important companies use shared servers to run their workloads, they would deserve it.

But I don't believe it. People are not that stupid.

[dgacmu]

I mean, you kinda can. There's a depressingly thriving market for stolen cards and things like compromised accounts. A card is a couple of dollars. There are many jurisdictions that turn a blind eye to hacking us companies. Look at how hard it's been to rein in the ransomware gangs and even 'booter' (ddos-for-rent) services.

DoS isn't as lucrative as other things; I assume that most state actors would far prefer to find a way to turn this into a privilege escalation. But being able to possibly take out a cloud provider for a while is still monetizable.

[blibble]

there exist people outside of your jurisdiction

e.g. the GRU

[TeMPOraL]

So Replit, Godbolt, and whatever other cloud-hosted compilers are there?

[sweetjuly]

The blogpost describes that unrelated sibling SMT threads can become corrupted and branch erratically. If you can get a hypervisor thread executing as your SMT sibling and you can figure out how to control it (this is not an if so much as a when), that's a VM escape. The Intel advisory acknowledges this too when they say it can lead to privilege escalation. This is hardly a useless bug, in fact it's awfully powerful!

[nrabulinski]

Intel themselves said it could lead to privilege escalation and a friend of mine (who coincidentally was responsible for this Intel-related talk: https://youtu.be/Zda7yMbbW7s) already managed to get privilege escalation with it, though I’m not sure if he’ll want to share any details, at least for now.

It’s anything but a minor bug and anyone that says so clearly hasn’t worked with CPUs

[derefr]

This assumes that either 1. partners and interested sponsor-state state actors aren't kept abreast Intel's microcode backend architecture, or 2. that there hasn't been at least one leak of this information from one of these partners into the hands of interested APT developers. I wouldn't put strong faith in either of these assumptions.

[ajross]

It does, but the same is true for virtually any such crash vulnerability. The question was whether this was a "valuable exploit", not whether it might theoretically be worse.

The space of theoretically-very-bad attacks is much larger than practical ones people will pay for, c.f. rowhammer.

[ethbr1]

>> Getting to a vulnerability would require understanding exactly how the corrupted microcode state works, and that seems extremely difficult outside of Intel.

Intel knows exactly how their ROB works.

Therefore Intel knows the possible consequences of this bug and how to trigger them.

If there is a privilege execution path from this, Intel knows. And anyone Intel chose to share it with knew.

Thankfully, since it's public now, the value of that decreases and customers can begin to mitigate.

[ajross]

> If there is a privilege execution path from this, Intel knows. And anyone Intel chose to share it with knew.

No, or at least not yet. I mean, I've written plenty of bugs. More than I can count. How many of them were genuine security vulnerabilities if properly exploited? Probably not zero. But... I don't know. And I wrote the code!

[saagarjha]

Intel said it can be used for escalation if that answers your question.

[lmm]

Did they confirm that it can definitely be used for escalation? The description I saw was "may allow an authenticated user to potentially enable escalation of privilege and/or information disclosure and/or denial of service via local access" which sounds like they're covering all their bases and may not actually know what is and isn't possible.