The followup tweet indicates that the CPU has to be in an unlocked state before this is possible, which on a typical system requires there to be a Management Engine vulnerability first. Given what we currently know, this is going to be interesting for people interested in researching the behaviour and security of Intel CPUs and might well lead to discovery of security issues in future, but in itself I don't think this is dangerous.
Edit to add: https://www.intel.com/content/dam/www/public/us/en/security-... is a discussion of a previous Intel security issue which includes a description (on page 6) of the different unlock levels. This apparently requires that the CPU be in the Red unlock state, which (in the absence of ME vulnerabilities) should only be accessible by Intel.
This seems like yet another thing on the list of “x86 hardware issues that sound worse than they are”.
I’m interested to see what people are able to reverse engineer with these sorts of tools. It wasn’t even that long ago that ucode wasn’t even encrypted with integrity. I don’t think AMD started doing that until around 2010.
I’m also curious which hardware versions this works on, since it’s not obvious it’s universal. I’ll be amused if it’s some forlorn low power chip from 10 years ago.
This would still break SGX/remote attestation, no? The chip can correctly say it's running some piece of assembly but if "ret" has been redefined to do whatever I want...
So you mean, if I am a state actor able to kidnap the child of an Intel high level employee... say I m Joe Biden, I can ask Intel to... remote unlock my CPU and read arbitrary memory block ?
Or you mean Intel had to physically handle your CPU with a debug cable or whatever ?
Cause I really dont feel it s okay that the only safety we have from a newly discovered exploit is that there needs to be another newly discovered exploit :D
Nothing against the original post (which just says what they found), but this seems to be really overblown. Yes, of course Intel has instructions to update the micro code, since that's a thing that they do. Neither is it particularly surprising that they didn't bother to document operations that only they would ever have reason to use (in their eyes). If, as sibling comment notes, you have to be in a specific unlocked state to use this instruction, it should be perfectly safe assuming someone hasn't compromised other layers of security. So yes, this is certainly interesting, and it could be used as part of a chain of exploits to do some really nasty things, but by itself this seems like barely news?
Look up "Intel VISA" if you want to go down one of the many rabbitholes of undocumented x86... it makes me sad that there are whole subsystems in the hardware whose documentation is not publicly available; not from the security perspective, but from the "I bet someone could do some really interesting things with this functionality" perspective, like what LOADALL enabled (unreal mode, real-mode paging, etc.) decades ago.
Intel isn't alone; search "9c5a203a" for some equally interesting stuff on the AMD side.
I've been down so many "rabbit holes" aka "levels of abstraction" aka "abstraction hierarchies" aka "turtles on top of turtles" aka "things stacked on top of other things" (compare with Monty Python's "society for putting things on top of other things") in my life as a Programmer (and in my secret life as an Philosopher! Shhh, don't tell anyone! <g>. And yes, I know... "Keep the day job"...<g>) that one more ("I'll go down this last rabbit hole, and then I'll be finished, really!") really won't make that much more difference! <g>
Before I get started on that one though, two more quick references about "abstraction hierarchies" aka "rabbit holes".
Now, I am not the member of any religion, I don't endorse any religious text over any other, but any intellectual worth his salt -- should read both of these writings, and compare them.
Once you've done that, then compare what's being said to abstraction hierarchies of all sorts.
We see abstraction hierarchies in code, we see them in language (especially when a language changes over many years, as it changes, fractures and sediments). We see them in Law (Law in the U.S. as it is practiced today can be compared to an abstraction hierarchy -- not at all unlike The Tower Of Babel as a metaphor for this phenomenon, or Joel's essay as a more complete modern-day explanation of it...)
We see them in a number of places and systems.
We even see them in x86-land...
That's because the x86 (as far as all of my research has suggested, and someone correct me if you think I am wrong, with links/references please!) -- is really a RISC core with a separate microcode execution engine (the level of abstraction above the RISC core), and has been since at least the Pentium Pro (P6, 1995):
>"The Intel technology is called Visualization of Internal Signals Architecture (VISA), and is used for manufacturing-line testing of chips.
However, Maxim Goryachy and Mark Ermolov, security researchers with Positive Technologies, said in a Thursday Black Hat Asia session that VISA can be accessed – and subsequently abused — to capture data from the CPU using a series of previously-disclosed vulnerabilities in Intel technology."
You know, that sort of reminds me of lyrics from The Who's "You Better You Bet":
"I showed up late one night with a neon light for a VISA,
But knowing I'm so eager to fight can't make letting me in any easier..."
Hmmm, now who is "me" in the above context?
?
Could it be... (With my apologies to SNL's Dana Carvey as "The Church Lady")... a TLA? (Three Letter... er, group? <g>)
Hey, if any power-that-be is offended, then I'd like them to know that I only quote things that I find on some places on the Internet -- on other places on the Internet....
In other words, I am only the messenger... one of millions and billions, that also quote things that they find on the Internet -- on other places on the Internet...
(Side note: There should be a Monty Python sketch for that topic! <g>)
In other words, "don't shoot the messenger...(s)" <g>...
It's absolutely incredible that I can't buy a processor and be able to run a command on the bare metal. We don't even know how many levels of indirection between x86 machine code and actual hardware there are.
The instruction in question looks to be encoded as 0f 0a. Which, sure enough, is missing from the official reference - https://files.catbox.moe/ktzqfg.png
the other appears to 0f 0e. at least if you go off this tweet. https://twitter.com/eigma/status/1373155650432290819 . 0f 0e is a 3DNow! instruction that AMD supported but not intel, which would explain why it has a mnemonic in Ghidra even though its undocumented for Intel processors.
As someone who isn't versed in computer hardware engineering, can nothing be done here? Why is it there is a new backdoor every few months? Is it an architecture issue, and we simply demand too much for too cheap? How do we lock this down?
This post is a nothing-burger. That an instruction exists that permits microcode updates is not new knowledge. Obviously there is one, if you can update microcode. All that's new here is reverse-engineering has filled in one of the holes in the Intel SDM.
The problem with microcode is that it’s specifically tailored to each specific microarchitecture. The microcode for, say, Skylake, won’t work on Haswell. And it definitely won’t work on any AMD CPU.
Intel and AMD almost certainly have compilers/assemblers of sorts that handles turning the microcode assembly-of-sorts into the correct bits, but they’re not portable.
None. Well, yeah, I think SiFive has HDL sources for quite a lot of their stuff up on GitHub, but it's not like you can just compile them into production silicon at home, heck, you can't even verify that the silicon was actually compiled from that source. (Yes there's research into verifiable silicon, but it's not like everyone has ultra high end electron microscopes and whatnot at home lol)
And of course nothing about RISC-V implies that production implementations will be open source at all.
I wonder what interesting things are in Apple's completely undocumented chips? There is that famous saying about known unknowns and unknown unknowns...
[+] [-] mjg59|5 years ago|reply
Edit to add: https://www.intel.com/content/dam/www/public/us/en/security-... is a discussion of a previous Intel security issue which includes a description (on page 6) of the different unlock levels. This apparently requires that the CPU be in the Red unlock state, which (in the absence of ME vulnerabilities) should only be accessible by Intel.
[+] [-] runjake|5 years ago|reply
[+] [-] strstr|5 years ago|reply
I’m interested to see what people are able to reverse engineer with these sorts of tools. It wasn’t even that long ago that ucode wasn’t even encrypted with integrity. I don’t think AMD started doing that until around 2010.
I’m also curious which hardware versions this works on, since it’s not obvious it’s universal. I’ll be amused if it’s some forlorn low power chip from 10 years ago.
[+] [-] dooglius|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] xwolfi|5 years ago|reply
Or you mean Intel had to physically handle your CPU with a debug cable or whatever ?
Cause I really dont feel it s okay that the only safety we have from a newly discovered exploit is that there needs to be another newly discovered exploit :D
[+] [-] yjftsjthsd-h|5 years ago|reply
[+] [-] intricatedetail|5 years ago|reply
[+] [-] userbinator|5 years ago|reply
Intel isn't alone; search "9c5a203a" for some equally interesting stuff on the AMD side.
[+] [-] the_only_law|5 years ago|reply
I will say, the thing security researchers find are simply amazing to me
[+] [-] peter_d_sherman|5 years ago|reply
I've been down so many "rabbit holes" aka "levels of abstraction" aka "abstraction hierarchies" aka "turtles on top of turtles" aka "things stacked on top of other things" (compare with Monty Python's "society for putting things on top of other things") in my life as a Programmer (and in my secret life as an Philosopher! Shhh, don't tell anyone! <g>. And yes, I know... "Keep the day job"...<g>) that one more ("I'll go down this last rabbit hole, and then I'll be finished, really!") really won't make that much more difference! <g>
Before I get started on that one though, two more quick references about "abstraction hierarchies" aka "rabbit holes".
On the one hand, we have Joel Spolsky's magnificent essay, "The Law of Leaky Abstractions (https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...) and on the other, we have the Biblical story of "The Tower Of Babel".
Now, I am not the member of any religion, I don't endorse any religious text over any other, but any intellectual worth his salt -- should read both of these writings, and compare them.
Once you've done that, then compare what's being said to abstraction hierarchies of all sorts.
We see abstraction hierarchies in code, we see them in language (especially when a language changes over many years, as it changes, fractures and sediments). We see them in Law (Law in the U.S. as it is practiced today can be compared to an abstraction hierarchy -- not at all unlike The Tower Of Babel as a metaphor for this phenomenon, or Joel's essay as a more complete modern-day explanation of it...)
We see them in a number of places and systems.
We even see them in x86-land...
That's because the x86 (as far as all of my research has suggested, and someone correct me if you think I am wrong, with links/references please!) -- is really a RISC core with a separate microcode execution engine (the level of abstraction above the RISC core), and has been since at least the Pentium Pro (P6, 1995):
https://stackoverflow.com/questions/5806589/why-does-intel-h...
http://i.blackhat.com/us-18/Thu-August-9/us-18-Domas-God-Mod... (Or Google "Christopher Domas God Mode Unlocked") (Also, see the patents listed in this PDF)
https://arxiv.org/pdf/1910.00948v1.pdf
https://troopers.de/events/troopers16/655_the_chimaera_proce... ("We take a 12-core processor, inject microcode to simulate a PowerPC (2 cores) and a MIPS processor (2 cores), restrict 2 cores to i386 and leave 4 cores to amd64.")
So with all this in mind, let's turn back and look at VISA:
https://threatpost.com/undocumented-intel-visa-tech-can-be-a...
>"The Intel technology is called Visualization of Internal Signals Architecture (VISA), and is used for manufacturing-line testing of chips.
However, Maxim Goryachy and Mark Ermolov, security researchers with Positive Technologies, said in a Thursday Black Hat Asia session that VISA can be accessed – and subsequently abused — to capture data from the CPU using a series of previously-disclosed vulnerabilities in Intel technology."
You know, that sort of reminds me of lyrics from The Who's "You Better You Bet":
"I showed up late one night with a neon light for a VISA,
But knowing I'm so eager to fight can't make letting me in any easier..."
Hmmm, now who is "me" in the above context?
?
Could it be... (With my apologies to SNL's Dana Carvey as "The Church Lady")... a TLA? (Three Letter... er, group? <g>)
Hey, if any power-that-be is offended, then I'd like them to know that I only quote things that I find on some places on the Internet -- on other places on the Internet....
In other words, I am only the messenger... one of millions and billions, that also quote things that they find on the Internet -- on other places on the Internet...
(Side note: There should be a Monty Python sketch for that topic! <g>)
In other words, "don't shoot the messenger...(s)" <g>...
[+] [-] lurtbancaster|5 years ago|reply
1. Like unofficially turning on ECC support on non-ECC chips assuming the hardware allows for it?
2. Or increasing total supported RAM size on lower end chips?
3. Unofficial open-source microcode updates(performance/security) for older unsupported chips?
[+] [-] Havoc|5 years ago|reply
Here is the timestamp
https://youtu.be/t9MjGziRw-c?t=585
[+] [-] konjin|5 years ago|reply
[+] [-] moonchild|5 years ago|reply
[+] [-] userbinator|5 years ago|reply
https://www.os2museum.com/wp/curious-instructions/
[+] [-] _kbh_|5 years ago|reply
[+] [-] tomrod|5 years ago|reply
[+] [-] jeffbee|5 years ago|reply
[+] [-] dreamcompiler|5 years ago|reply
[+] [-] colejohnson66|5 years ago|reply
Intel and AMD almost certainly have compilers/assemblers of sorts that handles turning the microcode assembly-of-sorts into the correct bits, but they’re not portable.
[+] [-] BlackLotus89|5 years ago|reply
Interesting comment on twitter to the instruction of the original post[1]
[0] https://www.youtube.com/watch?v=KrksBdWcZgQ&t=3
[1] https://twitter.com/eigma/status/1373155650432290819
[+] [-] 29athrowaway|5 years ago|reply
[+] [-] colejohnson66|5 years ago|reply
[+] [-] LockAndLol|5 years ago|reply
[+] [-] floatboth|5 years ago|reply
And of course nothing about RISC-V implies that production implementations will be open source at all.
[+] [-] ExcavateGrandMa|5 years ago|reply
[deleted]
[+] [-] BXLE_1-1-BitIs1|5 years ago|reply
[deleted]
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] bedros|5 years ago|reply
[+] [-] userbinator|5 years ago|reply
[+] [-] Daho0n|5 years ago|reply
[+] [-] baq|5 years ago|reply