27 ms·
Two Hidden Instructions Discovered in Intel CPUs Enable Microcode Modification
- coretx 5y agoClickbait. Only in debug mode.
- arbitrage 5y agoclever. thanks for the explanation.
- AnimalMuppet 5y agoNot quite. Only in "red state", which is a subset of debug mode. So, even more restrictive than what you said. But I still don't think that makes it clickbait. From the article: > The three researchers have posted a video demonstrating how to access the two instructions with only root/admin privileges. This requires uploading a custom UEFI to SPI flash and then rebooting the system, which definitely requires having physical access to it. So, not remote-able (at the moment). But there's enough there that I can't agree with calling it clickbait.
- fouric 5y agoEven aside from security vulnerabilities, wouldn't the ability to write your own microcode for Intel CPUs be interesting for many hobbyists?
- quotemstr 5y agoRight. Writing custom microcode can be useful for understanding fine details of the CPU's microarchitecture, which in turn is useful for things ranging from low-level optimization to discovering microarchitectural vulnerabilities that don't require custom microcode to exploit.
- yxhuvud 5y agoOr you can treat your Intel processor as a fpga and write instructions that do what you want them to. Unlocking features locked down to higher end machines is also not off the table. So it may or not be a security issue but it makes the machine hackable in a way it hasn't been before.
- rolph 5y agoshould you be capable enough to write your own microcode, there is an elevated chance that you could also encrypt and sign that code like intel microcode.
- marcan_42 5y agoNot unless you break RSA, which would be much more of an accomplishment than working out how microcode works.
- AnimalMuppet 5y agoFrom the article: > As a matter of fact, several vulnerabilities in Intel ME have been discovered in the past. Among others, Ermolov, Sklyarov, and Goryachy described a method to extract the secret key that is used inside the CPU to decrypt microcode updates, which also led to the possibility of executing your own microcode on the CPU or reading Intel's microcode. So you don't have to break RSA. You just have to use the private key to derive the public key, which I believe is do-able.
- spockz 5y agoEncryption and signing are two different things both using rsa keys. The public key used for encryption does not need to be part of the same key pair as the private key used for signing. Not sure whether this is the case here.
- SAI_Peregrinus 5y agoAlso they talk about a secret key, not a private key. That means it's likely using symmetric key encryption, with RSA for signing (and maybe to update the symmetric key a la RSA-KEM). This is normal, nobody does direct asymmetric message encryption.
- phire 5y agoIf the attacker is flashing custom ME firmware to flash, you are already well and truly fucked. They already have persistent and unlimited access to the ultimate back door and modifying the microcode isn't going to get them any extra access to your data or programs.
- AnimalMuppet 5y agoAt a minimum, though, this would be harder to detect. All of the usual places to look are completely unpatched.
- phire 5y agoBut it's not persistent by itself. You are going to need both a persistent modified ME firmware to enable red mode and some x86 code do the actual microcode modification on each boot. If the attacker has that, they can already do a traditional VM rootkit to hide their modifications.
- fulafel 5y agoA publicly documented cheap and reliable way to backdoor the cpu would bring this ME vector to many more people's radars.
- michaelmrose 5y ago> This requires uploading a custom UEFI to SPI flash and then rebooting the system, which definitely requires having physical access to it. Does this require something other than writing the file to the UEFI partition, setting it as the next boot target, and rebooting into that boot target? I tend to think I misunderstand because that would require root privileges under Linux but not physical access.
- phh 5y agoPersonally, I didn't understand the title as a security flaw. I simply understood it as a step forward into understanding/documenting the way Intel CPU work. So I don't think it is clickbait. The only part I'm not clear, is whether it was possible before? The article seem to imply that physical debugging tools (JTAG-like I presume) were already available to do uOP exploration?
- monocasa 5y agoYeah, previously the same team found a JTAG like mechanism that exposed microarchitectural internals like R/W access to microcode storage.
- deleted 5y ago[deleted]
- monocasa 5y agoNot quite clickbait. Previously there was no way to experiment with and introspect the changes in any Intel microcode updates. This gives unverified r/w to microcode update RAM, allowing reverse engineering of at least Apollo Lake updates and update mechanisms. I've been a little wigged out by the post spectre world of encrypted, unknown blobs changing every couple months. I prefer to treat vendors in a "trust in Allah, but tie up your camel" sort of way as much as possible.
- deleted 5y ago[deleted]
- squarefoot 5y agoI don't think they need to resort to clickbait articles. Dmitry Sklyarov is the same guy that 20 years ago was arrested by the FBI for DMCA violations when visiting the US because he, despite being a Russian citizen working for a Russian company (there's no DMCA in Russia), wrote a software that circumvented Adobe e-books copy protection. Had social media been around back then, #freedmitry would have been a trending hashtag like all similarly named sites that spawned shortly after the arrest. https://en.wikipedia.org/wiki/United_States_v._Elcom_Ltd https://en.wikipedia.org/wiki/United_States_v._Elcom_Ltd.
- swader999 5y agoUnless Twitter censored it.
- chx 5y agoWhen I was deciding on which country to immigrate to in 2006 I had three job offers: one from Canada, one from the US and from the UK so those were the potential targets. The CFAA and the Sklyarov case were among the major reasons I decided against the USA.
- ChuckMcM 5y agoI don't think you read the article closely enough. You only need "red state" (aka Debug mode) if you are using the instructions with unsigned microcode updates. But if you have a way to pop the machine into redstate you can exfiltrate the secret key and actually sign microcode changes that will be accepted as legit. All of those things are well within the capability of an APT, especially if you don't need the EXACT target system[1]. Personally I thought IME was a huge problem when Intel announced it, and I haven't changed that opinion. [1] Open question I don't know the answer too is whether all CPU SKUs share the same secret key. (which would be logical if you wanted to push a microcode change for a particular SKU).
- deleted 5y ago[deleted]
- mjg59 5y ago> But if you have a way to pop the machine into redstate you can exfiltrate the secret key and actually sign microcode changes that will be accepted as legit. No. The article mentions that the key required to decrypt microcode updates can be extracted. http://inertiawar.com/microcode/ http://inertiawar.com/microcode/ indicates that the encrypted microcode image is also signed, and being able to decrypt the image doesn't mean you can also generate an appropriate signature.
- marcan_42 5y agoMicrocode updates are signed with an asymmetric key ever since the Core line, so no, you can't "extract" the key because the only key the computers have is the public key, not the private key.
- ChuckMcM 5y agoI misread this paragraph: As a matter of fact, several vulnerabilities in Intel ME have been discovered in the past. Among others, Ermolov, Sklyarov, and Goryachy described a method to extract the secret key that is used inside the CPU to decrypt microcode updates, which also led to the possibility of executing your own microcode on the CPU or reading Intel's microcode. Where it talked about extracting the secret key.
- sabas123 5y agoThe article is based on the same tweet as this discussion from 3 months ago: https://news.ycombinator.com/item?id=26519693 https://news.ycombinator.com/item?id=26519693 I also want to state how impressive their work is. These are the true undocumented instruction finders as apposed to sandsifter.
- pabs3 5y agoWhats the difference between sandsifter and this work?
- colejohnson66 5y agoMy understanding is that sandsifter just detects byte sequences the processor decodes. That indicates an instruction the decoder recognizes, but gives nothing about what they do. This is about two specific instructions with a known purpose
- TacticalCoder 5y ago> on the good side of things, getting an Intel CPU to enter the red state is not easy to accomplish. In fact, it should never happen unless there are vulnerabilities in the Intel Management Engine (ME), an almost undocumented subsystem present in all Intel CPUs since 2008 that Intel says is required to provide full performance. "unless there are vulnerabilities or backdoors in the Intel Management Engine (ME)". There, fixed it for you.
- unnouinceput 5y agoThe IME itself is a backdoor in the first place. I remember a story a few years past when a full line of CPU's went out with IME having no password set at all, allowing a field day for hackers even when your computer was shut down but still receiving power on standby. Intel had to recall all of them but only after the news blew in media in the first place. Otherwise I'd suspect Intel would've just let it stay, cause money talks.
- google234123 5y agoLink?
- passivate 5y agoI'm in the minority, but I think IME is a great feature to have from a business/IT perspective. As a business, you own the computer, not the the user. And IME lets you provision/control it in at a lower level that most tools won't.
- dataflow 5y ago> it allows to craft your own persistent microcode patch without external debugger. These are persistent? Meaning they survive reboots? Is it stored in flash memory on the CPU or something? I thought all microcode updates are re-applied on each boot.
- sabas123 5y agoIf you would override the default microcode update, which should be doable if you have that level of access, you could call it persistent no?
- dataflow 5y agoNot really honestly. I mean, I thought the microcode update is done by the firmware and/or the OS on boot. Assuming that's correct, whether it's performed or not is entirely dictated by those entities... not by anything related to the CPU. It's like saying "I'm moving to New York" just because there's a car that drives you there from New Jersey every day. And if you really want to call that 'persistent', I'm not sure how one might have a non-persistent update in that case?
- tamrix 5y agoMicrocode updates have to be reapplied each time you restart your system.
- marcan_42 5y agoThey mean you could put code into your UEFI to apply the patch using these instructions on every boot, as opposed to the state of affairs until now, when you needed an external debugger connected via DCI to do the same thing. The CPU still needs to be in the Red state, which means you need to control ME. This applies to both cases.
- dataflow 5y agoOh I see! Thanks!
- intricatedetail 5y agoWhy is it legal to sell a device without providing full documentation, incl ME?
- selimnairb 5y agoCan you provide a legal definition of what "full documentation" would be?
- sudosysgen 5y agoA describition of every intentional design feature that is not immediately and obviously apparent.
- xxpor 5y agoYou don't need this to do anything with the CPU that was promised when you bought it.
- intricatedetail 5y agoWhat do you mean? What if I want to change the microcode to something I like?
- edoceo 5y agoThat wasn't a product claim that Intel made. Its like warranty void if opened, no user serviceable parts inside. There is no legal obligation to sell you an open and fully-documented CPU.
- jkaplowitz 5y ago"warranty void if opened" is also illegal in most consumer cases in the US, as common as it is for companies to apply this policy without being challenged on it, and certainly in many other countries. Of course, they are certainly allowed to refuse to service warranty claims where a third-party part or repair caused the problem. Source: https://www.ftc.gov/news-events/blogs/business-blog/2018/04/ftc-staff-sends-warranty-warnings https://www.ftc.gov/news-events/blogs/business-blog/2018/04/... (blog post on the official FTC site - look at the third bullet point in their examples) Not mentioned in the above source, but the burden of proof that the third-party part or repair caused the problem is on the warrantor, not the consumer.
- anonymousDan 5y agoI wonder are there implications for Intel SGX?
- rasz 5y agoIn theory this should open possibility to unlock all the market segmentation gated Intel bullshit like ECC, AVX, multiplier change overclocking, etc. Maybe even manipulating CPUID.
- mhh__ 5y agoMaybe, but that might be risky in the sense that if a chip has completely faulty behaviour at high clock speed (I'm not familiar with how they bin things in practice) they can sell it as a low speed one. Intel like to segment their products, but it's not completely for profit.
- sudosysgen 5y agoYou can just stress test your cpu for a day after and roll it back if it crashes or makes a mistake.
- dannyw 5y agoYeah but things like ECC are totally artificially segmented. It's an identical memory controller.
- monocasa 5y agoI've heard on the grapevine that binning decisions like that are made with fuses and lasers. ECC might even be another mask.
- rasz 5y agoAt least max multiplier limit is definitely switchable in microcode. In 2013 Intel released microcode update changing multiplier limit when the CPU is on h81/b85/h87 boards. In 2015 they even somehow convinced Microsoft to push this microcode globally in an update. https://bit-tech.net/news/tech/cpus/intel-overclocking-block/1/ https://bit-tech.net/news/tech/cpus/intel-overclocking-block... Before microcode - full overclock, after microcode update - locked multipliers.
- marcan_42 5y ago
- Jerry2 5y agoIt's interesting that they submitted a paper for a talk at BLACK HAT USA 2021 but were rejected [0]. Looks like geopolitics (and politics) has permeated every aspect of technology. [0] https://twitter.com/h0t_max/status/1397441062705057793 https://twitter.com/h0t_max/status/1397441062705057793
- timeinput 5y agoHow did they find these instructions? Did they just try things while in the red state?
- egberts1 5y agoRejected? Not a problem. Upcoming talks on Red Pill for Intel Atom. https://zeronights.ru/en/reports-en/chip-red-pill-how-we-achieved-to-execute-arbitrary-microcode-inside-intel-atom-cpus/ https://zeronights.ru/en/reports-en/chip-red-pill-how-we-ach...
- FpUser 5y ago>" Dmitry Sklyarov" I assume he is that famous guy from Elcomsoft who put Adobe and DOJ to shame. Good to know he is still productive.
- userbinator 5y agoMy initial guess was "WRMSR, and the 64-bit version of WRMSR". Fortunately, this appears to be an actually new finding rather than the memorable case a few years back of someone claiming to have discovered something that was clearly documented in the datasheet. The whole idea that there's a "red state" and a bunch of others on a CPU, normally hidden, should immediately raise the attention of many who wonder what those extra modes can do, and more interestingly, why they're hidden. From the (very little!) research I've done, it appears this is not unlike SGX where only Intel has the key[1] to some part of the hardware you bought from them, and based on some leaked internal documents, it's very plausible that this is indeed a backdoor which only they can use. Ostensibly, for debugging purposes. Here's a previous comment I made on this: https://news.ycombinator.com/item?id=26521359 https://news.ycombinator.com/item?id=26521359 [1] If these keys were leaked, which I very much hope will happen at some point, no doubt the "security" community will be heavily against it and spread plenty of FUD about how it makes everyone's computers insecure. But IMHO it should be eagerly awaited and received with the same optimism as the other DRM key leaks (HDCP, HDDVD, etc.) --- it is a path to freedom.
- londons_explore 5y agoI assume it will be a public-private keypair with some challange-response mechanism, so no amount of reverse engineering could extract the key from a CPU. Intel probably have the master private key on a hardware security module, and have set up some API so their engineers can do the challange-response dance to get into RED mode. But after poweroff, it'll need to be done again. If that's the setup, the key won't leak. There are probably only 5 hardware cards in the world with the key, and they're probably set to not allow key extraction. To get the key, you would need to physically steal the card, and have an exploit for silicon designed to be key storage... Not going to happen.
- jhoechtl 5y agoAnd the key on the silicon would auto-destroy if a fraudulent attempt is recognized.
- marcan_42 5y agoTL;DR 1. If you control Intel Management Engine (exploit/backdoor/whatever), you have full control over the system. 2. That full control comes with, among everything else, the ability to put the CPU in a deep debug state ("Red Unlock") 3. In Red Unlock, you can basically play with the CPU's internals at will using a debug cable (just a modified A-A USB3 cable on many modern systems; "DCI"). 4. It turns out that in Red Unlock state there are also undocumented instructions that let you do the same thing straight from code running on the CPU itself. Notice how the security relevance stops at #1. We already know that if you control ME, you control the system. So there is no security impact to this discovery. The prerequisite is already total control. Also notice how what these instructions let you do isn't new. The same researchers already showed how to do the same thing via an external debugger (CRBUS access) last year. So this does not open any new capabilities for CPU research. What it does do is make things more convenient. Now you can do this without an external debugger, "only" with an ME patch/exploit and code running on the system itself, which means you could e.g. have it apply custom microcode patches on every boot (by patching your UEFI firmware to do it). Also, the USB debug thing doesn't work on all motherboards (some are missing the required connections), while this would work.
- Lammy 5y ago> Notice how the security relevance stops at #1. Security of a single PC, or security of an entire operation? Seems like this would be a great "in" for personalized unattended exploits of airgapped systems, kinda like what Stuxnet/Flame/Duqu were famous for but at an even lower level.
- marcan_42 5y agoYou still need to compromise ME, at which point there are a million easier ways to accomplish your goals than a microcode patch. For example, SMM is much easier to compromise and arguably more powerful (you can hide large amounts of code in SMM, not so in microcode); SMM backdoors that interact with userspace code have already been demonstrated. Or you could do something in ME directly, which again has plenty more space to hide stuff in than microcode. The point is this isn't a bug, it's a feature; if you've gotten the CPU into red unlock anyway, you are already thoroughly screwed. This is like saying if you install a development version of an OS and enable remote debugging, you can take over the machine remotely. Well.... yes. This is interesting because it's undocumented, not because it has security implications.
- deleted 5y ago[deleted]
- ozfive 5y agoThis title should have been appended with " in debug mode."
- johnswas 5y agoSurveillance is already on CPU level, sadly.