There was an interesting black hat talk about automatically finding undocumented instructions. [0]
Interesting comment on twitter to the instruction of the original post[1]
Undocumented x86 instructions in Intel CPUs that can modify microcode
101–110 of 145 posts
Re: Undocumented x86 instructions in Intel CPUs that can modify microcode
#102Earlier quoted context omitted.
Firmware is not protected by Secure Boot . It can be protected by things like Boot Guard, but at least that one (Intel's) requires pairing the board and the CPU, so it can only be done in laptops and other prebuilt OEM systems.
What do you mean by firmware here? Microcode? No it's not. But as long as you only load bootloaders or operating systems that are signed, it doesn't matter that they could fiddle with the bits as long as the signature guarantees they don't (in any undesired way). Or ME? Well, that seems to be a complete security nightmare.
Microcode is protected by its own signing thing, IIUC.
Firmware is both ME firmware and x86 firmware — the UEFI implementation, FSP, everything else that runs on early boot.
Re: Undocumented x86 instructions in Intel CPUs that can modify microcode
#103Earlier quoted context omitted.
Plot twist: there’s been a few ME vulnerabilities. And who knows what other purposeful ME backdoors there may or may not be.
Sure, which is why this is useful to researchers. But the access someone needs to your system in order to exploit the ME vulnerabilities is sufficiently extreme that if someone achieves it you probably have other things to worry about.
Am I correct in surmising that a successful run of me_cleaner will prevent the abuse of these instructions?
Re: Undocumented x86 instructions in Intel CPUs that can modify microcode
#104Earlier quoted context omitted.
In most cases there is a public API which is documented and a private API which is not. In this specific case, users do not have the ability to use this instruction, so there is no reason to document it.
Why is it acceptable for companies to keep such information away from a consumer?
Here's how Ford tests its car seats: https://www.theverge.com/tldr/2019/1/11/18178402/ford-robot-...
Should we, as consumers, demand that Ford productize this robot and make it publicly available before we'll buy a Ford car?
Re: Undocumented x86 instructions in Intel CPUs that can modify microcode
#105Earlier quoted context omitted.
Because it is not part of the public-accessible product and the company is free to change it at will from one version of the product to the other, or even between multiple batch of the same version. You see it from an "they should inform us" POV, but there is also the "there is no guarantee it will be there" side.
What do you mean it's not publically accessible? A bank's vault is not publically accessible because there is a meter of steel, concrete, and armed guards. We can debate if some private bank API's are publically accessible (you can still DDOS them). This shit, however, is inside my property, that I bought with my money, and it might end up being used by some malware. It is by definition accessible, and could be a sec…
You're talking security, he was talking official documentation and thus guarantees about it being there that way.
Your bank doesn't guarantee you that the lock model X45-b from company SUPERLOCK will protect your gold in their vault, even if that's what they use right now, and it's not specified in your contract with them, they just guarantee to protect your gold. This way they can change the lock without being in breach of contract.
Re: Undocumented x86 instructions in Intel CPUs that can modify microcode
#106The 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 thi…
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...
I would love ability to redefine call/ret to profile an app without compiler generate diff code.
Re: Undocumented x86 instructions in Intel CPUs that can modify microcode
#107Earlier quoted context omitted.
Why would they do that?
I can't imagine why someone would hide details of the product they are selling. That is dishonest and should be illegal. Imagine if someone was selling food and would omit some ingredients from the list or you buy a house with a basement and you don't get a key nor info what's inside.
[deleted]
Re: Undocumented x86 instructions in Intel CPUs that can modify microcode
#108Earlier quoted context omitted.
In most cases there is a public API which is documented and a private API which is not. In this specific case, users do not have the ability to use this instruction, so there is no reason to document it.
Why is it acceptable for companies to keep such information away from a consumer?
Whether or not it is acceptable it is certainly the standard method used.
Even websites often have an internal API and a different public-facing one.
This is how almost everything works in the digital age.
Re: Undocumented x86 instructions in Intel CPUs that can modify microcode
#109Earlier quoted context omitted.
Sure, which is why this is useful to researchers. But the access someone needs to your system in order to exploit the ME vulnerabilities is sufficiently extreme that if someone achieves it you probably have other things to worry about.
I can't get with justifying one serious security problem using another. Attackers increasingly combine local privilege escalations to move laterally, but only need one RCE to get in.
Windows can be booted into test keys mode, which allows the loading of unsigned drivers. We don't consider that a security issue because the privileges you need in order to switch to that mode are equivalent to the privileges you get by switching to that mode. It's the same here - the ME is the root of trust on Intel platforms. If you're in a position to execute arbitrary code on the ME then you've already got the ability to compromise the rest of the system enough to run arbitrary code on the host CPU, and being able to modify microarchitectural state doesn't give you additional privileges.
Re: Undocumented x86 instructions in Intel CPUs that can modify microcode
#110Earlier quoted context omitted.
Can you give an example of a processor whose microcode was publicly documented? (Barely-public documents like patent filings don't count.)
For the 6502 there were manuals that detailed how many clock ticks every instruction takes and what happens during the ticks, which is pretty much the same.
I don't know what era you are pining for.
The original 6502 had many undocumented instructions. Most of them not very interesting, but certainly undocumented. http://nesdev.com/undocumented_opcodes.txt
Here is a detailed examination of undocumented Z80 behavior. http://www.z80.info/zip/z80-documented.pdf
The 8080 had undocumented instructions too.
So now we are all the way back to pdp series. The pdp-8 had plenty of undocumented instructions.
Should we go back further? It doesn't stop.