3 ms·

Yes, everyone will accept the microcode update. TSX is still pretty new and I doubt a lot of code uses it. Intel tends to phase features like this in over a few

by exelius 12y ago

Yes, everyone will accept the microcode update. TSX is still pretty new and I doubt a lot of code uses it. Intel tends to phase features like this in over a few generations of CPUs for this reason. The only real impact is that code that relied on TSX would need to rely on fallback methods of accomplishing the same tasks. Since there's probably not much of that floating around, there's very little impact at this time.

sillysaurus3 12y ago
How do CPU vendors issue a microcode update such that no hacker could make their own malicious update? It's obviously a cryptographically signed update, and the CPU checks that the update is signed by the expected key, but does that mean every CPU is hardcoded to check for a specific key? What happens if that key is compromised? Is every CPU at risk forever at that point, or can the CPU be updated via software to check for a newly issued key? Also, were is the private key stored? Some vault somewhere? How would a CPU vendor know if the key had been surreptitiously copied, and some rogue group was issuing malicious updates to a specific target's CPU? Is it even advantageous for an attacker to have the capability of issuing microcode updates to a target computer? What sort of attacks could you mount via microcode updates?
- 0x0 12y ago
  I think they are mostly undocumented, but here is some research I found online: http://inertiawar.com/microcode/ http://inertiawar.com/microcode/ I'm guessing the private RSA keys are extremely well guarded, probably stored in a HSM that only allows signing, not key extraction, so that the keys cannot even be revealed to Intel. On the other hand, who knows. There's certainly been cases of code signing keys on the loose (Adobe, etc) and even a compromised HSM host (Fedora, someone managed to sign compromised openssh .rpms)
  - exelius 12y ago
    Given that Intel processors largely run the servers that the modern world runs on, I would expect that the NSA/CIA has done a full security audit of their microcode processes. The US government is nothing if not thorough about these types of potential security issues.
    - pgeorgi 12y ago
      And in exchange for that audit they gained permission to get their own microcode updates signed, too?
      - amluto 12y ago
        I'm not sure why they'd want it. Unless there's secret non-volatile storage on Intel chips, there's relatively little of value that you can do using a rogue microcode update. This is because Intel chips reset to factory microcode when rebooted. It's plausible that a rogue microcode update could be used to bypass TPM static-root-of-trust protections, though, and a microcode update could certainly bypass TXT's dynamic root of trust. This might enable a bootable USB stick that would load malicious microcode and then reboot warmly enough to preserve the microcode and then launch the OS with a TXT bypass. Even so, I don't really see the point. So far, essentially every BIOS can be freely (or freely using an exploit) reflashed from kernel mode, and a new image could contain malicious SMM code, and SMM code can also bypass both static and dynamic roots of trust.
        xorcist 12y ago
        There are plenty interesting things you could do in processor firmware. Here are three examples: Tamper with AES and randomness instructions. Plant a very obscure privilege escalation exploit. Given the prevalence of java, activex and google nacl, escaping sandboxes is a big thing. Tamper with the MMU to make a certain software invisible. If they had the opportunity, it's not unlikely they did something like this. Perhaps just in a directed attack. They've done extensive firmware patching in the past in you believe last year's leaks. A more interesting question is whether they didn't have to, because they had a say in making the silicon in the first place. The risk is there, it's not crazy to see it. Even FreeBSD who was the last mainstream OS to use the randomness instructions unadultered doesn't do that anymore.
        pgeorgi 12y ago
        Make RDRAND less random, store AESNI key data in a place you can later exfiltrate it from, provide SMM capabilities to the current execution context with some magic opcode (I grant that the latter is easier done through a malicious firmware update - but that's also easier to detect, since x86 code is a known format)... Modulo the microcode signature, flash is better locked down these days: Flash updates are typically arbitrated by the firmware (though that's also just one signature away), requiring a reboot, while microcode updates are still free for all (in ring0 - realtek already lost a driver signing key once, why not again?).
- exelius 12y ago
  Putting my tinfoil hat on for a moment, these are the exact types of attacks that China and the US are alleged to have executed. I would trust Intel to lock down security on microcode updates (which is exactly why you can't find the answers to any of the questions you asked), but I would also trust that state actors (i.e. spies backed by a trillion dollar economy) have the resources to break any security that any one company could dream up. I would guess that the first layer of protection comes from limiting the scope of microcode updates. Perhaps there's a semiconductor engineer out there who knows more?
  - 0x0 12y ago
    Well. Microcode updates are lost on reboot, and they can only be applied from privileged code. Which means you'll have to be able to slip rogue code into the BIOS or the kernel, at which point you already have full control. The "negative ring" levels of code (SMI, etc) are quite powerful already. But a trojanized microcode update file inside an otherwise regular BIOS would be a nice hiding spot, hard to detect and analyze, at least for anyone outside Intel.
    - AlyssaRowan 12y ago
      Or you could just use SMM or IPMI.
      - sillysaurus3 12y ago
        Use those how? Would you go into detail?
        amluto 12y ago
        See, for example: http://www.eecs.ucf.edu/%7Eczou/research/SMM-Rootkits-Securecom08.pdf http://www.eecs.ucf.edu/%7Eczou/research/SMM-Rootkits-Secure... If you're an OS, then you need some kind of exploit to update SMM code. But if you're the BIOS, then you have complete control over what happens in SMM mode.

by exelius 12y ago

sillysaurus3 12y ago

How do CPU vendors issue a microcode update such that no hacker could make their own malicious update? It's obviously a cryptographically signed update, and the CPU checks that the update is signed by the expected key, but does that mean every CPU is hardcoded to check for a specific key? What happens if that key is compromised? Is every CPU at risk forever at that point, or can the CPU be updated via software to check for a newly issued key? Also, were is the private key stored? Some vault somewhere? How would a CPU vendor know if the key had been surreptitiously copied, and some rogue group was issuing malicious updates to a specific target's CPU? Is it even advantageous for an attacker to have the capability of issuing microcode updates to a target computer? What sort of attacks could you mount via microcode updates?

0x0 12y ago
I think they are mostly undocumented, but here is some research I found online: http://inertiawar.com/microcode/ http://inertiawar.com/microcode/ I'm guessing the private RSA keys are extremely well guarded, probably stored in a HSM that only allows signing, not key extraction, so that the keys cannot even be revealed to Intel. On the other hand, who knows. There's certainly been cases of code signing keys on the loose (Adobe, etc) and even a compromised HSM host (Fedora, someone managed to sign compromised openssh .rpms)
- exelius 12y ago
  Given that Intel processors largely run the servers that the modern world runs on, I would expect that the NSA/CIA has done a full security audit of their microcode processes. The US government is nothing if not thorough about these types of potential security issues.
  - pgeorgi 12y ago
    And in exchange for that audit they gained permission to get their own microcode updates signed, too?
    - amluto 12y ago
      I'm not sure why they'd want it. Unless there's secret non-volatile storage on Intel chips, there's relatively little of value that you can do using a rogue microcode update. This is because Intel chips reset to factory microcode when rebooted. It's plausible that a rogue microcode update could be used to bypass TPM static-root-of-trust protections, though, and a microcode update could certainly bypass TXT's dynamic root of trust. This might enable a bootable USB stick that would load malicious microcode and then reboot warmly enough to preserve the microcode and then launch the OS with a TXT bypass. Even so, I don't really see the point. So far, essentially every BIOS can be freely (or freely using an exploit) reflashed from kernel mode, and a new image could contain malicious SMM code, and SMM code can also bypass both static and dynamic roots of trust.
      - xorcist 12y ago
        There are plenty interesting things you could do in processor firmware. Here are three examples: Tamper with AES and randomness instructions. Plant a very obscure privilege escalation exploit. Given the prevalence of java, activex and google nacl, escaping sandboxes is a big thing. Tamper with the MMU to make a certain software invisible. If they had the opportunity, it's not unlikely they did something like this. Perhaps just in a directed attack. They've done extensive firmware patching in the past in you believe last year's leaks. A more interesting question is whether they didn't have to, because they had a say in making the silicon in the first place. The risk is there, it's not crazy to see it. Even FreeBSD who was the last mainstream OS to use the randomness instructions unadultered doesn't do that anymore.
      - pgeorgi 12y ago
        Make RDRAND less random, store AESNI key data in a place you can later exfiltrate it from, provide SMM capabilities to the current execution context with some magic opcode (I grant that the latter is easier done through a malicious firmware update - but that's also easier to detect, since x86 code is a known format)... Modulo the microcode signature, flash is better locked down these days: Flash updates are typically arbitrated by the firmware (though that's also just one signature away), requiring a reboot, while microcode updates are still free for all (in ring0 - realtek already lost a driver signing key once, why not again?).
exelius 12y ago
Putting my tinfoil hat on for a moment, these are the exact types of attacks that China and the US are alleged to have executed. I would trust Intel to lock down security on microcode updates (which is exactly why you can't find the answers to any of the questions you asked), but I would also trust that state actors (i.e. spies backed by a trillion dollar economy) have the resources to break any security that any one company could dream up. I would guess that the first layer of protection comes from limiting the scope of microcode updates. Perhaps there's a semiconductor engineer out there who knows more?
- 0x0 12y ago
  Well. Microcode updates are lost on reboot, and they can only be applied from privileged code. Which means you'll have to be able to slip rogue code into the BIOS or the kernel, at which point you already have full control. The "negative ring" levels of code (SMI, etc) are quite powerful already. But a trojanized microcode update file inside an otherwise regular BIOS would be a nice hiding spot, hard to detect and analyze, at least for anyone outside Intel.
  - AlyssaRowan 12y ago
    Or you could just use SMM or IPMI.
    - sillysaurus3 12y ago
      Use those how? Would you go into detail?
      - amluto 12y ago
        See, for example: http://www.eecs.ucf.edu/%7Eczou/research/SMM-Rootkits-Securecom08.pdf http://www.eecs.ucf.edu/%7Eczou/research/SMM-Rootkits-Secure... If you're an OS, then you need some kind of exploit to update SMM code. But if you're the BIOS, then you have complete control over what happens in SMM mode.