Hacker News Reader

Comment by shmde | Hacker News Reader

As someone who just makes Crud apps can someone please ELI5 this. Why is this a big deal and why are people freaking out about intel chips becoming obsolete overnight ?

View on HN

A CPU executes the machine instructions of your program (you might think of this as "assembly" programs, like "put a zero in register 12" or "jump to address 0xFF3392"). There have been architectures where instructions map directly onto transistors, but since System/360 (*) there's an extra level: the CPU has it's own, lower-level programming language that's used to execute the machine instructions. Finding out how a CPU actually works is interesting per se, and very valuable for competitors, but this work might also expose vulnerabilities and/or backdoors, built into the chip itself. It seems to be around 100kB of code, so there's a whole lot of opportunity...

(*) first commercial architecture I know of...

As someone still at the "piecing things together" stage, here's my understanding:

There are a bunch of privilege levels in Intel CPUs (https://en.wikipedia.org/wiki/Protection_ring, relatively boring), used for memory protection and user/kernel mode separation (IIUC, I think I'm correct). They can be controlled by whatever code boots the CPU ("gets there first"), because the CPU boots in the most trusting state.

Over time the set of available levels proved insufficient for security and new levels were added with negative numbers so as not to disrupt the existing status quo. Ring -1 is used for virtualization and can also be controlled by whatever boots first (ie, outer code can create VMs and enter them, but the CPU faults if inner code attempts to access the virtualization instruction set), but Ring -2 and Ring -3 are used by the CPU itself.

Essentially, in the same way whatever the bootloader loads gets control over a bunch of interesting functionality because that code got there first, Ring -2 and -3 are controlled by code running directly on the CPU that gained control of the system before the bootloader and in some cases even UEFI was started. The significant elements are that a) this code can theoretically be altered by system (microcode) updates; b) these components run *completely* independently of the operating system - IIRC, the Management Engine is based on Minix running on a tiny 486-class core somewhere on the CPU die; and c) this invisible functionality has the ability to read and write all of system RAM. What's that? A glitch? A couple of bytes of RAM just got modified? That made the running Linux kernel suddenly think a process's effective UID is 0? Must have been the butterfly effect!

A bit of Googling found this overview of Ring -1 to -3 which I'd say is really good, definitely worth clearing your cookies to read if Medium is yelling at you about subscribing:

https://medium.com/swlh/negative-rings-in-intel-architecture...

> definitely worth clearing your cookies to read if Medium is yelling at you about subscribing:

I've been getting a lot of mileage out of "scribe.rip" that was posted a while back (https://news.ycombinator.com/item?id=28838053)

https://scribe.rip/swlh/negative-rings-in-intel-architecture...

Wow, this is really neat. Thanks!

If there is a backdoor, it could be widely exposed. And such a hypothetical backdoor may not be patchable AT ALL.

As in, there may a possibility for almost every computer being vulnerable to a RCE that bypasses even the OS.

> And such a hypothetical backdoor may not be patchable AT ALL.

Intel microcode can be loaded at runtime. If there's a backdoor in the microcode then it can, by definition, be patched.

Pretty sure the microcode could be changed to deny a patch, since it has the most privileged level of control on the system.

Microcode isn't persistent - on reboot you'll be running whatever version was in the CPU at manufacturing time. That means there's a path to booting to a known-good environment and updating the firmware, which will then load patched microcode before any attacker-controlled code can run.

As I understand it, you would need to have an existing RCE to exploit the microcode patching process.

h0t_max’s research means that future attacks — once your local machine has been infiltrated by some other means — can do a lot more damage than simply encrypting your filesystem or sending spam. They can rewrite the way your CPU works.

When your OS gets attacked by malware it is attacking the layer above the bare metal on which your OS runs. The base hardware remains untouched. You can at least clean things up by installing a new OS on the bare metal.

If malware attacks the bare metal itself, then you are stuck out of luck.

As mentioned in the github page that this post links to, it's impossible to make a custom microcode update because the updates are RSA signed.

Except if someone finds a flaw in the microcode loader.

Didn’t they dump the private keys?

Why would private keys be on the chip?

Public key

What can do they with the public key vs private key?

Public keys can only be used to verify a signature, not to sign anything.

Was the public key found used to decrypt the microcode?

If there exists a backdoor, its unlikely to be remotely accessible. But privesc for any OS running a vulnerable CPU, absolutely. This would probably look like some hidden instruction to load and execute an arbitrary ELF at the XuCode level, not a magic packet.

Cant the intel ME already bypass the OS and connect to the network?

I'm unfamiliar with it, but that would still be initiated from the host itself, not an attacker on another machine.

>"But privesc for any OS running a vulnerable CPU, ..." What is privsec here?

Not privsec, privesc -> PRIVilege ESCalation.

Isn't the point of the microcode to make it possible to patch a HW bug?

It takes microcode to patch microcode though. AFAIK.

If the malware shuts that patching off...

Your OS loads a microcode update in to the CPU very early in the boot process, it's not a static firmware. Unless the microcode malware is sophisticated enough to block e.g. windows update, debian mirrors, then updating the system and rebooting to load a patched microcode would be sufficient to flush this out.

Depending on where the vulnerability exists it can be patched by patching the microcode right?

It isn't. There is unnecessary hysteria. Encrypting microcode is just usual competitive play. Doesn't mean anything nefarious. If issues are found in the said microcode, that would be a different story.

Microcode does spill the secrets of the hardware, so definitely don’t want competitors looking through.

Old ones though are open book (of a sort).

The 6502 for the apple II was obviously hand generated so it microcode is weird, but the 68k for the original Mac was pretty normal microcode as we would think of it today.

The 6502 is not microcoded, or at least not in the way we presently conceive of microcode. Its operations are driven by an on-board PLA which controls decoding and sequencing with its gates, which also explains its high performance per clock. It would be hard to call those gate connections micro-opcodes since they're not really used in that sense.

The 6502 uses "horizontal microcode", which, as you said, are the individual control lines. x86 uses "vertical microcode" which is a sort-of internal RISC architecture.

I did say it was weird… ;)

People think that if they would find out that Intel CPUs were designed to spy for Russians, the entire world will switch to AMD.

Reality: nobody cares.

> Reality: nobody cares.

I'd like to talk about how we patch this pervading cynicism and replace it with a model that's actually useful.

It isn't true on face value. Consider the course of the Cov19 pandemic. Two things spread. One was a virus. The other was an idea, news about a virus. The latter spread much faster than the former. It spread because people love "doom". Any story about the impending "end of everything" is lapped up, relished and shared by the public.

There are well understood stages to information propagation. After "Is this real?" and "Am I affected?" comes the question of "what to do?"

I think this is where your assertion about "care" comes in. Some events will blow-up and burn out fast. People run around like headless chickens enjoying the drama about something remote to their lives, but ultimately nobody can do anything, so focus recedes. Wars and famines are like that. Curtis calls this "Oh Dearism".

Alternatively, if there is any residual effect, new events connected to the initial story, it feeds and grows. The initial "All the chips are broken!" story that would die after a 24 hour news cycle becomes an ongoing "situation". Then people care, because it's cool to care. It gets a catchy handle "Evil-Inside" and a news slogan "The chips are down". And then it won't go back in the bottle.

To reformulate your "Nobody cares" - as a question - "Do people have sensible cares that are proportionate to the threat?" No. But if the media tells them to care because cars are running off the road and there's a massive uptick in cybercrime, which nobody can ignore and is directly attributable to a single cause, then the "care" (hysteria) can get worse than the problem (which may have happened with Cov19 to some degree).

Finally, they may care, but about completely the wrong thing. One suspects, if it turns out there is indeed some serious drama in Intel chips, then Intel and the US government will try to paint the security researchers as irresponsible hackers who unleashed this upon the world.

The whole world would remove and replace that 5G equipment.

Reply on news.ycombinator.com