10 ms·

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 ove

by shmde 4y ago

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 ?

Akronymus 4y ago
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.
- spockz 4y ago
  Depending on where the vulnerability exists it can be patched by patching the microcode right?
- mjg59 4y ago
  > 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.
  - pitaj 4y ago
    Pretty sure the microcode could be changed to deny a patch, since it has the most privileged level of control on the system.
    - mjg59 4y ago
      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.
- gorgoiler 4y ago
  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.
  - ndiddy 4y ago
    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.
    - anewpersonality 4y ago
      Didn’t they dump the private keys?
      - sroussey 4y ago
        Public key
        deleted 4y ago
        [deleted]
        anewpersonality 4y ago
        What can do they with the public key vs private key?
        pitaj 4y ago
        Public keys can only be used to verify a signature, not to sign anything.
- stonepresto 4y ago
  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.
  - Akronymus 4y ago
    Cant the intel ME already bypass the OS and connect to the network?
    - stonepresto 4y ago
      I'm unfamiliar with it, but that would still be initiated from the host itself, not an attacker on another machine.
  - bogomipz 4y ago
    >"But privesc for any OS running a vulnerable CPU, ..." What is privsec here?
    - na85 4y ago
      Not privsec, privesc -> PRIVilege ESCalation.
- sschueller 4y ago
  Isn't the point of the microcode to make it possible to patch a HW bug?
  - Akronymus 4y ago
    It takes microcode to patch microcode though. AFAIK. If the malware shuts that patching off...
    - rrix2 4y ago
      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.
vbezhenar 4y ago
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.
- nonrandomstring 4y ago
  > 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.
- sroussey 4y ago
  The whole world would remove and replace that 5G equipment.
tgv 4y ago
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...
exikyut 4y ago
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 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-the-security-threats-youve-probably-never-heard-of-d725a4b6f831 https://medium.com/swlh/negative-rings-in-intel-architecture...
- mdaniel 4y ago
  > 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://news.ycombinator.com/item?id=28838053) https://scribe.rip/swlh/negative-rings-in-intel-architecture-the-security-threats-youve-probably-never-heard-of-d725a4b6f831 https://scribe.rip/swlh/negative-rings-in-intel-architecture...
bubblethink 4y ago
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.
- sroussey 4y ago
  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.
  - classichasclass 4y ago
    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.
    - sroussey 4y ago
      I did say it was weird… ;)
    - colejohnson66 4y ago
      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.

by shmde 4y ago

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 ?

Akronymus 4y ago

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.

spockz 4y ago
Depending on where the vulnerability exists it can be patched by patching the microcode right?
mjg59 4y ago
> 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.
- pitaj 4y ago
  Pretty sure the microcode could be changed to deny a patch, since it has the most privileged level of control on the system.
  - mjg59 4y ago
    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.
gorgoiler 4y ago
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.
- ndiddy 4y ago
  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.
  - anewpersonality 4y ago
    Didn’t they dump the private keys?
    - sroussey 4y ago
      Public key
      - deleted 4y ago
        [deleted]
      - anewpersonality 4y ago
        What can do they with the public key vs private key?
        pitaj 4y ago
        Public keys can only be used to verify a signature, not to sign anything.
stonepresto 4y ago
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.
- Akronymus 4y ago
  Cant the intel ME already bypass the OS and connect to the network?
  - stonepresto 4y ago
    I'm unfamiliar with it, but that would still be initiated from the host itself, not an attacker on another machine.
- bogomipz 4y ago
  >"But privesc for any OS running a vulnerable CPU, ..." What is privsec here?
  - na85 4y ago
    Not privsec, privesc -> PRIVilege ESCalation.
sschueller 4y ago
Isn't the point of the microcode to make it possible to patch a HW bug?
- Akronymus 4y ago
  It takes microcode to patch microcode though. AFAIK. If the malware shuts that patching off...
  - rrix2 4y ago
    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.

vbezhenar 4y ago

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.

nonrandomstring 4y ago
> 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.
sroussey 4y ago
The whole world would remove and replace that 5G equipment.

tgv 4y ago

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...

exikyut 4y ago

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 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-the-security-threats-youve-probably-never-heard-of-d725a4b6f831 https://medium.com/swlh/negative-rings-in-intel-architecture...

mdaniel 4y ago
> 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://news.ycombinator.com/item?id=28838053) https://scribe.rip/swlh/negative-rings-in-intel-architecture-the-security-threats-youve-probably-never-heard-of-d725a4b6f831 https://scribe.rip/swlh/negative-rings-in-intel-architecture...

bubblethink 4y ago

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.

sroussey 4y ago
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.
- classichasclass 4y ago
  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.
  - sroussey 4y ago
    I did say it was weird… ;)
  - colejohnson66 4y ago
    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.