Plot twist: there’s been a few ME vulnerabilities. And who knows what other purposeful ME backdoors there may or may not be.

No, no! You've got it wrong. It's a backdoor when Huawei does it. When Intel does it, it's just a vulnerability/oversight/mistake. /s

Sure, which is why this is useful to researchers. But the access someone needs to your system in order to exploit the ME vulnerabilities is sufficiently extreme that if someone achieves it you probably have other things to worry about.

I can't get with justifying one serious security problem using another. Attackers increasingly combine local privilege escalations to move laterally, but only need one RCE to get in.

Windows can be booted into test keys mode, which allows the loading of unsigned drivers. We don't consider that a security issue because the privileges you need in order to switch to that mode are equivalent to the privileges you get by switching to that mode. It's the same here - the ME is the root of trust on Intel platforms. If you're in a position to execute arbitrary code on the ME then you've already got the ability to compromise the rest of the system enough to run arbitrary code on the host CPU, and being able to modify microarchitectural state doesn't give you additional privileges.

I’m not saying that’s the case here, but that’s the general problem with the line of reasoning that “hey if you already have permission X then doing Y is the least of your concerns”.

The concept of defense in depth literally relies on each barrier being independent and robust. That’s why you see hardening of Linux’s hibernate even though the common refrain is “well if you have physical access the game is lost”. There are things that even root can’t do even though “hey if you have root the game is lost”. The point of the game is to never lose even in very adverse environments.

The assumption on Intel is that there are no barriers once you're in the ME. You can't defend against a hostile ME. The security model is already violated. Maybe there should be a barrier between the ME and the CPU, but as can be seen here Intel feel that the ME should be in a position to put the CPU in debug mode so shrug.

Where can I read about "hardening of Linux’s hibernate"? I'm curious

I suppose one possible scenario is:

- Police confiscate your laptop on some bogus pretext, then return it to you saying you're free to go.

- You open the laptop and find nothing that shouldn't be there. You wipe it, reinstall the OS and continue using the laptop.

- Surprise! The CPU now works for the police, so after some time it installs a rootkit or whatever.

Dunno if the microcode is big enough to do this kind of attacks, and perhaps some other firmware is easier to program.

But if someone waves this off saying that's not how police works in the US, well the world is larger than the US and it all definitely happens in other countries, only without CPU rootkits so far.

Situation without this CPU feature: Cops compromise the ME, disable Boot Guard, compromise your firmware, backdoor your OS directly Situation with this CPU feature: Cops compromise the ME, disable Boot Guard, compromise your firmware, backdoor your CPU so it can later backdoor your OS

There's not really a meaningful difference between these! If there's an exploitable ME vulnerability then the police can absolutely own your system in an undetectable way regardless of whether or not this feature exists. If we were in a different universe where the ME enabled whether or not the CPU was in debug mode but wasn't responsible for any other security features then we'd care about this a great deal more, but as long as compromising the ME already gives you a way to permanently backdoor the system it's doesn't make any real difference.

You mean NSA and the same, but online?

There are more productive ways to view the probabilities of security. Low probability may imply low risk but is not guaranteed to imply low priority to fix.

Am I correct in surmising that a successful run of me_cleaner will prevent the abuse of these instructions?

No. me_cleaner reduces the amount of code running on your ME, and as such reduces the attack surface presented by the ME. But anyone with physical access (which is required for the interestingly exploitable ME vulnerabilities) is in a position to just put whatever ME firmware they want on your system.

Yeah, like a rootkit on the cpu.

Or the only thing to worry about

This seems like yet another thing on the list of “x86 hardware issues that sound worse than they are”.

I’m interested to see what people are able to reverse engineer with these sorts of tools. It wasn’t even that long ago that ucode wasn’t even encrypted with integrity. I don’t think AMD started doing that until around 2010.

I’m also curious which hardware versions this works on, since it’s not obvious it’s universal. I’ll be amused if it’s some forlorn low power chip from 10 years ago.

>It wasn’t even that long ago that ucode wasn’t even encrypted with integrity

whether they're encrypted or not doesn't really matter. what actually matters is whether they're signed or not. There was a talk given in 2017 about trying to modify the microcode in AMD processors, but they were using processors from a decade ago (AMD K10, introduced 2007). That makes me think that processors made in the past decade are probably using signed microcode.

Is it this one? https://www.usenix.org/system/files/conference/usenixsecurit...

Yeah, although I didn't find the original paper. Reading into it more, they mention when AMD and Intel started signing their microcode.

>Note that Intel started to cryptographically sign microcode updates in 1995 [15] and AMD started to de-ploy strong cryptographic protection in 2011 [15].

This would still break SGX/remote attestation, no? The chip can correctly say it's running some piece of assembly but if "ret" has been redefined to do whatever I want...

The keys are stripped out if you put it into the required unlock mode.

That would be a good thing, given what those features are usually used for (DRM and other user-hostility).

I would love ability to redefine call/ret to profile an app without compiler generate diff code.

Can’t you do that through ebpf?

My understand of ebpf can hook into the function calls in linux kernel.

Can one do that on user space app?

Yes, that is my understanding.

This is what I'm interested in since they pushed that so heavily.

It is public knowledge that US intelligence agencies actually just hijack computers and equipment on their way to the customer and install hardware backdoors there (Snowden et al., 2014).

It is also known that they have had backdoors in commercial systems as they came off the shelf, but I think usually those were CIA owned and controlled companies like the crypto AG phones.

What is unknown (pure speculation) is whether, for example, Intel CPUs come backdoored straight from the factory floor? On the one hand, that would be a powerful capability to have, but on the other hand, the risk of exposure and subsequent damage to the US economy, prestige, etc. would be non-zero. So it's hard (for a plebian like me, anyway) to estimate how those costs/benefits might be weighed up by the US government.

>What is unknown (pure speculation) is whether, for example, Intel CPUs come backdoored straight from the factory floor?

There is also a third possibility, that some intelligence agency invested a ton of cash into finding abusable exploits in these systems giving them the same access a backdoor would provide.

Also from the Snowden leaks, we know that they have programs with budgets in the millions into finding similar exploits and that there were similar programs outside Snowden's clearance. And though a bug may cause the same damage to the economy, it wouldn't hurt US prestige in the same way.

If I'm the CIA I have dozens of highly placed agents or at least informants at Intel. Not necessarily placing backdoors, but finding and not fixing exploits and sending them back to the CIA for later use. It would be extremely cheap, hell if I'm China, Russia, the UK, or Israel I'm doing the same thing.

You don't even Intel employees for that. State actors typically get source access for 'verfication' purposes.

Russia and China would get Windows source access for instance.

Budgets in the millions, eh? So two full-time engineers?

Sorry, I misremembered the details. Around $400 million a year for the one program we have details on.

> On the one hand, that would be a powerful capability to have, but on the other hand, the risk of exposure and subsequent damage to the US economy, prestige, etc. would be non-zero

If I were a three-letter agency, I'd bribe/blackmail somebody into inserting intentionally vulnerable code. After all, sufficiently advanced malice is indistinguishable from incompetence.

We've often seen that the code inside firmware, secure environments like trustzone, etc tend to lack many of the mitigations for the classic vulnerabilities. Just rewrite one of the ASN.1 parsers in the ME (I'm sure there's at least one), "forget" a bounds check in some particularly obscure bit, and you'd have a textbook stack smash.

You don’t need to bribe anyone; Intel is a US company, so A TLA can just discretely explain to them how export restrictions work.

Subtly change the RNG implementation so there’s a predictability only you know.

That’s one of the reasons why operating systems provide a proper CPRNG instead of trusting RDRAND.

How would an OS seed an RNG in the cloud? How would you seed an RNG on a headless server in a VM? What about when that VM is copied, possibly while running, in order to duplicate server functionality? There are vulnerabilities and threats here that your comment does not take into account.

You can use virtio_random.

But really, it's not about operating systems not using RDRAND at all - it's fine to use it as one of the entropy sources; what you don't want to do is use RDRAND directly instead of CPRNG.

Remotely? I think Intel would need to produce a backdoored ME firmware, get the system vendor to incorporate that into a system update and then convince the target to flash that. In that sense I don't know that they'd technically need physical access, but it doesn't really meet most people's description of a remote attack.

Don't use CPUs from companies that have employees that can be kidnapped.

Don't use CPUs from companies that have employees.

Don't use anything

Don't be so paranoid. Just build your own CPU from discrete NAND gates like everyone else.

A pen and paper is everything you need.

But what if it’s some of that fancy paper or a pen that records everything you write! Might need to manufacture your own pen and paper now...

Hold up there you don't know if someone's been tampering with the trees, you'll have to grow your own forest first

The “trusting trust” flaw still applies, better sequence your own species of tree.

And trust the same chemical processes that eventually resulted in the mess we’re in? Start a new universe.

I guess out of business CPU companies are one easily accessible category.

While true, it's pretty likely their IP was sold to still-in-business companies. ;)