6 ms·

Notes on Intel Microcode Updates

161 points by fejr 13y ago

ffrryuu 13y ago
The NSA probably got the private key so they can reprogram your CPU.
- Guvante 13y ago
  The private keys for SSL are orders of magnitude more valuable and much easier to get ahold of.
- zokier 13y ago
  I would be quite impressed if NSA had the ability to write microcode updates themselves. I'd imagine they are not exactly trivial and require intimate knowledge of the actual silicon.
  - ffrryuu 13y ago
    You just need 1 mole inside Intel. I've been to multiple large corps, there are no secrets once you are in. Plus, NSA has the capability to reverse engineer chips at the physical level.
    - ballard 13y ago
      Donning tinfoil hat, NSA is just one part of USG. USG is one of hundreds of countries, zillions of criminal enterprises that would like to get intel's private keys and μcode format. Given that intel is a large company the odds favor one/more external actors having access. There's really no way to know without some sort of way for IDS to check μcode. Never going to happen due to the blackbox nature of closed, proprietary systems.
      - XorNot 13y ago
        Or we could all just realize that for the time and effort of trying to write a backdoor into a general purpose CPU, which would need huge amounts of memory to be remotely capable of keeping track of code execution and to correctly make an OS remotely exploitable (you know, involving the network stack, probably TCP/IP and other things) rather then just crashing it...that it easier just to email someone an executable saying "I love you.exe" and wait for them to run it. This is looking through the microscope to determine whether a forest is on fire.
        ffrryuu 13y ago
        Denying the truth won't make the problem go away.
    - nullc 13y ago
      > there are no secrets once you are in. Which is why this guy is feeling around in the dark with bit-errors, because even though there are no secrets on the inside not a single one of intel's 104k employees is willing to throw this guy a bone. Right.
- RachelF 13y ago
  Maybe, it will be one of the harder exploits to code, but very effective to disable certain apps or hide other backdoors. Reprogramming the microcode would be a virus-writer's dream come true, too. Knowing how to do it is probably very hard, as it is probably some RTL. Intel started releasing reprogrammable microcode after the FDIV bug in the original Pentium made them replace a few hundred thousand CPUs. With programmable microcode, they could replace this operator.
mrb 13y ago
I wonder what is the attack scenario that the RSA signature of the microcode is supposed to protect? An attacker flashing a microcode that introduces specially-crafted bugs in certain instructions, in order to create backdoors?
- rdl 13y ago
  Bricking your $3000 CPU?
  - mrb 13y ago
    Microcode updates are volatile. Rebooting cancels them.
    - DuskStar 13y ago
      Bad drivers included with the original 8.1 preview builds had a habit of permanently bricking mobile 700 series gpus - I'm sure you could do the same with a microcode update! Imagine setting the default voltage to 5v and multiplier to something crazy high, and disabling thermal cutoff - unless you happen to be dumping LN2 on your cpu at the time, it's probably not going to survive!
      - djcapelis 13y ago
        Microcode updates shouldn't effect the thermal integrity of the processor. Microcode updates update a specific part of the processor that does a specific thing, i.e. the translation between the input ISA and the processor's native microcode instruction set, it's not supposed to be a wholesale update of processor parameters. (But we don't know enough about the structure of microcode updates to be certain. But I think you're barking up the wrong tree here and likely should read up on how Intel processors actually use microcode.) You certainly can brick a CPU by updating parameters like that, but you wouldn't typically update parameters like that via a microcode update.
        shabble 13y ago
blahbl4hblah 13y ago
NSA, NSA, and NSA...also...NSA. THIS NEVER GETS OLD!!!!
spydum 13y ago
I find analysis like this thoroughly fascinating. I wonder if the handful of Intel engineers who presumably crafted this would ever stumble into this post. Would they be impressed, or alarmed that someone is probing such a crucial mechanism?
- djcapelis 13y ago
  Having talked with some Intel engineers about their microcode, they consider it a company secret that protects trade secrets about how their processors function and wouldn't say much of anything about it. I suspect they would be slightly impressed that someone was able to find out as much as they did, but I don't think they would be overly surprised. I also suspect they would also be satisfied that this doesn't disclose anything sensitive about the contents of the microcode updates and just found out some information about the mechanism. They definitely wouldn't be surprised that someone was probing microcode updates. A lot of us have asked them about it and they know people are interested about what's going on inside those blobs. > I wonder if the handful of Intel engineers who presumably crafted this would ever stumble into this post. They almost certainly will if they haven't already.
  - smalley 13y ago
    Yup, a lot of folks at the office enjoy skimming hacker news, ars technica etc. The number of people capable of actually signing microcode even in a company of 100,000+ is pretty darn small though. You'd actually be surprised about how much effort goes into hardening things against attacks like those these days (timing attacks, differential power analysis etc). There's a lot of interesting work around on the best ways of mitigating those risks.
kens 13y ago
It's amazing how much someone can determine about a "secure" system by poking at it, doing differential attacks, and timing attacks. Anyone trying to build something secure should take warning from this, especially since there are much, much more determined attackers. As someone reverse-engineering the Z-80, I find this article interesting. Maybe 35 years from now, someone will post a full analysis of how this Intel chip processes microcode internally, answering all the questions raised by this article. It will be very interesting to find out if there's anything malicious in any microcode patches. Are there checksums of the microcode so you can make sure you're not getting "special" microcode updates? Reply to mrb: I expect 90% of the purpose of the signature is to protect against untested or corrupted updates getting installed. (It would be a support nightmare if people installed microcode with errors.) Protecting against deliberate attacks is probably secondary; I doubt you could do a nontrivial attack without inside help.
- akira2501 13y ago
  Fortunately, microcode updates are not persistent across boots.
  - nly 13y ago
    And how do we know that is really the case? It could be partially persistent and you'd never know it.
    - akira2501 13y ago
      To do that it would require some type of persistent memory on the CPU itself. You could open the chip and look for memory of this type, it requires certain special features to operate, and they're somewhat easy to pick out of a chip shot. There's also an engineering reason to avoid doing this: persistent memory cells based on silicon have a limited number of write cycles.
taway2012 13y ago
Can somebody explain what extra security they gained by using an RSA-based signature as opposed to a straight-up HMAC (with the secret key burned into the CPU)?
- AsymetricCom 13y ago
  Extra complexity. I imagine if there is a presumably existing secret key, that it's generated at run time by properties of the environment combined with the logic in the update to have known results for each chip, then matching logic is presumably part of an operation where the math is dependent on the key matching or "fitting". Thus you can get (some of) the security of an arbitrary length key without explicitly recording what that key exactly is. You could spread out the mechanisms and various individual incremental tests of the "lock" throughout the update operation code so that an attacker would have to completely understand the entire codebase just to understand the locking mechanism instead of the locking mechanism being self contained function with a pass/fail output.
- caf 13y ago
  This way all the CPUs out there contain the information required to verify an update, but not the information required to create a verifiable update. If there was a secret key burned into the CPU, you can be sure that it would eventually be discovered.
  - taway2012 13y ago
    Maybe I'm missing something: the public key is present in the microcode update blob (according to the article), and CPU itself must have corresponding private key within it. The sender uses the public key to sign, the receiver uses the private key to verify. If we stipulate that info burned into the CPU isn't secure against extraction, then an attacker can get the private key. Obviously, he can obtain the public key much more easily from then update blob. And now they can generate malicious updates. The security of even the RSA system seems to rest on the difficulty of extracting the private key from the CPU. Am I missing something?
    - 13y ago
losethos 13y ago
http://forum.osdev.org/viewtopic.php?f=13&t=22683&p=183195&hilit=microcode+jamesm#p183195 http://forum.osdev.org/viewtopic.php?f=13&t=22683&p=183195&h... Someone said simple instructions are not microcode.
andyjohnson0 13y ago
Some previous discussion on this: https://news.ycombinator.com/item?id=5485035 https://news.ycombinator.com/item?id=5485035 Also: https://news.ycombinator.com/item?id=5351672 https://news.ycombinator.com/item?id=5351672

161 points by fejr 13y ago

ffrryuu 13y ago

The NSA probably got the private key so they can reprogram your CPU.

Guvante 13y ago
The private keys for SSL are orders of magnitude more valuable and much easier to get ahold of.
zokier 13y ago
I would be quite impressed if NSA had the ability to write microcode updates themselves. I'd imagine they are not exactly trivial and require intimate knowledge of the actual silicon.
- ffrryuu 13y ago
  You just need 1 mole inside Intel. I've been to multiple large corps, there are no secrets once you are in. Plus, NSA has the capability to reverse engineer chips at the physical level.
  - ballard 13y ago
    Donning tinfoil hat, NSA is just one part of USG. USG is one of hundreds of countries, zillions of criminal enterprises that would like to get intel's private keys and μcode format. Given that intel is a large company the odds favor one/more external actors having access. There's really no way to know without some sort of way for IDS to check μcode. Never going to happen due to the blackbox nature of closed, proprietary systems.
    - XorNot 13y ago
      Or we could all just realize that for the time and effort of trying to write a backdoor into a general purpose CPU, which would need huge amounts of memory to be remotely capable of keeping track of code execution and to correctly make an OS remotely exploitable (you know, involving the network stack, probably TCP/IP and other things) rather then just crashing it...that it easier just to email someone an executable saying "I love you.exe" and wait for them to run it. This is looking through the microscope to determine whether a forest is on fire.
      - ffrryuu 13y ago
        Denying the truth won't make the problem go away.
  - nullc 13y ago
    > there are no secrets once you are in. Which is why this guy is feeling around in the dark with bit-errors, because even though there are no secrets on the inside not a single one of intel's 104k employees is willing to throw this guy a bone. Right.
RachelF 13y ago
Maybe, it will be one of the harder exploits to code, but very effective to disable certain apps or hide other backdoors. Reprogramming the microcode would be a virus-writer's dream come true, too. Knowing how to do it is probably very hard, as it is probably some RTL. Intel started releasing reprogrammable microcode after the FDIV bug in the original Pentium made them replace a few hundred thousand CPUs. With programmable microcode, they could replace this operator.

mrb 13y ago

I wonder what is the attack scenario that the RSA signature of the microcode is supposed to protect? An attacker flashing a microcode that introduces specially-crafted bugs in certain instructions, in order to create backdoors?

rdl 13y ago
Bricking your $3000 CPU?
- mrb 13y ago
  Microcode updates are volatile. Rebooting cancels them.
  - DuskStar 13y ago
    Bad drivers included with the original 8.1 preview builds had a habit of permanently bricking mobile 700 series gpus - I'm sure you could do the same with a microcode update! Imagine setting the default voltage to 5v and multiplier to something crazy high, and disabling thermal cutoff - unless you happen to be dumping LN2 on your cpu at the time, it's probably not going to survive!
    - djcapelis 13y ago
      Microcode updates shouldn't effect the thermal integrity of the processor. Microcode updates update a specific part of the processor that does a specific thing, i.e. the translation between the input ISA and the processor's native microcode instruction set, it's not supposed to be a wholesale update of processor parameters. (But we don't know enough about the structure of microcode updates to be certain. But I think you're barking up the wrong tree here and likely should read up on how Intel processors actually use microcode.) You certainly can brick a CPU by updating parameters like that, but you wouldn't typically update parameters like that via a microcode update.
      - shabble 13y ago

blahbl4hblah 13y ago

NSA, NSA, and NSA...also...NSA. THIS NEVER GETS OLD!!!!

spydum 13y ago

I find analysis like this thoroughly fascinating. I wonder if the handful of Intel engineers who presumably crafted this would ever stumble into this post. Would they be impressed, or alarmed that someone is probing such a crucial mechanism?

djcapelis 13y ago
Having talked with some Intel engineers about their microcode, they consider it a company secret that protects trade secrets about how their processors function and wouldn't say much of anything about it. I suspect they would be slightly impressed that someone was able to find out as much as they did, but I don't think they would be overly surprised. I also suspect they would also be satisfied that this doesn't disclose anything sensitive about the contents of the microcode updates and just found out some information about the mechanism. They definitely wouldn't be surprised that someone was probing microcode updates. A lot of us have asked them about it and they know people are interested about what's going on inside those blobs. > I wonder if the handful of Intel engineers who presumably crafted this would ever stumble into this post. They almost certainly will if they haven't already.
- smalley 13y ago
  Yup, a lot of folks at the office enjoy skimming hacker news, ars technica etc. The number of people capable of actually signing microcode even in a company of 100,000+ is pretty darn small though. You'd actually be surprised about how much effort goes into hardening things against attacks like those these days (timing attacks, differential power analysis etc). There's a lot of interesting work around on the best ways of mitigating those risks.

kens 13y ago

It's amazing how much someone can determine about a "secure" system by poking at it, doing differential attacks, and timing attacks. Anyone trying to build something secure should take warning from this, especially since there are much, much more determined attackers. As someone reverse-engineering the Z-80, I find this article interesting. Maybe 35 years from now, someone will post a full analysis of how this Intel chip processes microcode internally, answering all the questions raised by this article. It will be very interesting to find out if there's anything malicious in any microcode patches. Are there checksums of the microcode so you can make sure you're not getting "special" microcode updates? Reply to mrb: I expect 90% of the purpose of the signature is to protect against untested or corrupted updates getting installed. (It would be a support nightmare if people installed microcode with errors.) Protecting against deliberate attacks is probably secondary; I doubt you could do a nontrivial attack without inside help.

akira2501 13y ago
Fortunately, microcode updates are not persistent across boots.
- nly 13y ago
  And how do we know that is really the case? It could be partially persistent and you'd never know it.
  - akira2501 13y ago
    To do that it would require some type of persistent memory on the CPU itself. You could open the chip and look for memory of this type, it requires certain special features to operate, and they're somewhat easy to pick out of a chip shot. There's also an engineering reason to avoid doing this: persistent memory cells based on silicon have a limited number of write cycles.

taway2012 13y ago

Can somebody explain what extra security they gained by using an RSA-based signature as opposed to a straight-up HMAC (with the secret key burned into the CPU)?

AsymetricCom 13y ago
Extra complexity. I imagine if there is a presumably existing secret key, that it's generated at run time by properties of the environment combined with the logic in the update to have known results for each chip, then matching logic is presumably part of an operation where the math is dependent on the key matching or "fitting". Thus you can get (some of) the security of an arbitrary length key without explicitly recording what that key exactly is. You could spread out the mechanisms and various individual incremental tests of the "lock" throughout the update operation code so that an attacker would have to completely understand the entire codebase just to understand the locking mechanism instead of the locking mechanism being self contained function with a pass/fail output.
caf 13y ago
This way all the CPUs out there contain the information required to verify an update, but not the information required to create a verifiable update. If there was a secret key burned into the CPU, you can be sure that it would eventually be discovered.
- taway2012 13y ago
  Maybe I'm missing something: the public key is present in the microcode update blob (according to the article), and CPU itself must have corresponding private key within it. The sender uses the public key to sign, the receiver uses the private key to verify. If we stipulate that info burned into the CPU isn't secure against extraction, then an attacker can get the private key. Obviously, he can obtain the public key much more easily from then update blob. And now they can generate malicious updates. The security of even the RSA system seems to rest on the difficulty of extracting the private key from the CPU. Am I missing something?
  - 13y ago

losethos 13y ago

http://forum.osdev.org/viewtopic.php?f=13&t=22683&p=183195&hilit=microcode+jamesm#p183195 http://forum.osdev.org/viewtopic.php?f=13&t=22683&p=183195&h... Someone said simple instructions are not microcode.

andyjohnson0 13y ago

Some previous discussion on this: https://news.ycombinator.com/item?id=5485035 https://news.ycombinator.com/item?id=5485035 Also: https://news.ycombinator.com/item?id=5351672 https://news.ycombinator.com/item?id=5351672