5 ms·
Clickbait. Only in debug mode.
by coretx 5y ago
Clickbait. 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.