Full control over the Intel backdoor / remote administration engine that's on all their modern CPUs. (It may not be an intentional backdoor, but it's certainly looking as if it's been usable as one by intelligence agencies.)
OK so the implication being that with this thing found, someone could make a USB device that when plugged into an intel machine immediately gets control?
Reading http://www2.lauterbach.com/pdf/dci_intel_user.pdf, there are two ways to debug over that connector; one using the USB protocol and the other using a proprietary protocol. If this uses the latter, that device, technically, wouldn’t have to be a USB device (but of course, it could still masquerade as one)
That PDF also says your BIOS must support this kind of debugging, and, for the ‘OOB’ protocol, your hardware must support it. So, your BIOS may be configurable to make this attack impossible, and your hardware may already be protected against it.
‘Simply’ may mean entering, possibly cracking, the BIOS password (hm, are there BIOSes that use two-factor authentication?). It also means you can’t simply plug in a USB device.
Intels own guidelines say that DCI should be disabled by default, although on some systems that was not true[1], afaik (would like to be corrected if wrong) this does not impact vast majority of systems. This seems more like a frontdoor that is supposed to be locked tight rather than an backdoor. The bugs that actually enable DCI could be more likely candidates to be considered backdoors.
But once that front door is open, people will be able to walk around in the house and figure out how to 1) finally disable the thing for good, or 2) find a more universal attack that doesn't use that door.
As long as I know, is not in 'all' their modern CPUs. Just all the CPUs with vPro feature, that aren't the ones used in domestical environments but large businesses.
You're talking about AMT (which runs on the Intel ME - Management Engine). The ME itself, however, is on every CPU (running Minix on Skylake and later CPUs, ThreadX on earlier models), because one of the responsibilities of the ME, apart from being a backdoor, is to manage the CPU: power it on, handle power signals, etc. The CPU wouldn't run without the ME, so it's necessary that it's on all CPUs.
As well as physical access do you also need to set a bios setting? It isn't entirely clear to me but the background information article linked in this thread seems to suggest yes.
Not quite true. Currently it requires physical access with a JTAG debugger. Presumably eventually it could be weaponized enough to allow access with any sort of USB device, and potentially remotely, but the latter is very unlikely.
Regarding Intel ME/AMT: how does it work when the computer is powered off? On a wired network, I imagine some system which stores the nearest switch's port connected to that machine, and you could send some sort of signal which powers things up. But even that seems, impossible? I guess it's not unlike hitting the power button; you're just sending an electrical signal to the computer which makes it start. The path of that signal is unimportant.
Regardless of AMT there is standard protocol to remotely wake computers over ethernet (since mid-90's or so). NIC that supports it can be powered from 5Vsb and in that mode listens for specially formatted ethernet frame (format is somewhat configurable, but by default it consists of several repetitions of NIC's MAC in payload, actual destination MAC is unimportant as long as the frame passes through configured receive filters) which causes it to pull down wire going into motherboard's power management logic (and thus causing the same thing as pressing power button). This usually has to be enabled by BIOS and thus does not work in S0 (as is the case for almost all wakeup sources except physical power button, which is usually wired such that it unconditionally shorts PSU's PS_ON wire to ground and does not need any software configuration to cause wakeup). Probably all onboard NICs support this and for PCI cards this requires additional cable between NIC and motherboard, PCIe includes required wires as pins B10 and B11 (with 3.3V instead of 5V and with active detection that inserted card is actually capable of generating wakeup events).
If I correctly understand how AMT works then it implements it's own mechanism with similar purpose inside ME firmware, which with AMT enabled remains active even in S5.
Am I right in understanding that ALL Intel based computers are now a huge security risk?
It's really puzzling that Intel would risk the entire company to include features like this. Even if the NSA said "we demand it", surely this is possibly the end of Intel being a trustable computing platform?
The deeper question being, how can any cloud based program know that it is running on a computer safe from such snooping? Is there any possible way or do we just need to give up on that idea forever and assume that what runs on someone elses computer might be monitored and nothing can be done about it.
> Apple, and perhaps other manufacturers, insist it not be there.
I have an off-topic question about that statement. I fail to grammatically parse the construct "A and B insist C no be there". Doesn't it need to be "A and B insist C is not there"?
Do you have any support for this claim? I've heard of the HAP backdoor to disable the subsystem, but it's only available to 3 letter agencies as far as anyone knows.[0]
My experience with JTAG (and it's been a little while since I've used it) is that the device clock must be stopped before you can read the instrumented flip-flops. This is because they're serialized together, meaning you shift them out of the device one at a time using a special JTAG clock signal. You can use JTAG to essentially get a view of the device's state at the moment you stop the clock, but if you keep the clock running you get a trashed device state as you shift the flop values through the serialized chain. (You can also shift values back in and restart the clock, but this may or may not work depending on how many flops you can access via the JTAG chain.)
In other words, I'm not sure how you can use this to modify running devices without being able to stop the clock first. Is this something that JTAG supports now?
which acces does it have? is it a tty to minix with root login? or did intel at least protected it for whichever is the agency that requested that with a "zero day" local privileged escalation? ;)
We see full read access to the hidden and protected 0xf008 pages, so you can dump the kernel and all running minix processes. The kernel is not interesting, but the processes are.
I expect a message from Intel that it was bad idea to place ME in the CPU and that in the future Intel would not do such things ... but that would be only a PR bullshit.
First thing Intel would do is to implement/create new ME-like thing, maybe on other arch like ARK before and hide it little more.
Then finally someone would find it anyway in a few years and let others know about it ...
I hope somebody dumps all the code from CSME and reverse engineers it to a higher level language next. I'm sure few more surprises can be expected to be found.
It's a very common way for such "hacking" events. Finally getting through PlayStation X, iPhone Y or whatever security is often shown through a screen shot like this. Proper explanation and details come later.
64 comments
[ 3.0 ms ] story [ 50.1 ms ] threadEdit: I read some more. It looks like this is going beyond what I thought and affects way more machines.
That PDF also says your BIOS must support this kind of debugging, and, for the ‘OOB’ protocol, your hardware must support it. So, your BIOS may be configurable to make this attack impossible, and your hardware may already be protected against it.
[1] https://security-center.intel.com/advisory.aspx?intelid=INTE...
https://security-center.intel.com/advisory.aspx?intelid=INTE...
You could spy on user activity, sniff encryption keys etc
If I had to guess, I wouldn’t be surprised if a different exploit is found that bypasses the bios setting to compliment this one.
http://www.tomshardware.com/news/mantistek-gk2-collects-type...
but invisible and undetectable
https://www.digitaltrends.com/computing/intel-kaby-lake-skyl...
Intel has put CSME and DCI in all (?) their chips since 2015. Skylake was announced in 2014, launched in 2015.
I can see use-cases for it, but good luck convincing the W3C.
If I correctly understand how AMT works then it implements it's own mechanism with similar purpose inside ME firmware, which with AMT enabled remains active even in S5.
It's really puzzling that Intel would risk the entire company to include features like this. Even if the NSA said "we demand it", surely this is possibly the end of Intel being a trustable computing platform?
The deeper question being, how can any cloud based program know that it is running on a computer safe from such snooping? Is there any possible way or do we just need to give up on that idea forever and assume that what runs on someone elses computer might be monitored and nothing can be done about it.
I have an off-topic question about that statement. I fail to grammatically parse the construct "A and B insist C no be there". Doesn't it need to be "A and B insist C is not there"?
Any sources for IME being completely disabled / not present on macs?
[0]https://www.theregister.co.uk/2017/08/29/intel_management_en...
Intel's large scale customers wanted this feature. To Intel, it has been a net asset instead of a liability, and maybe this will still hold up.
In other words, I'm not sure how you can use this to modify running devices without being able to stop the clock first. Is this something that JTAG supports now?
Even though it's run over the same wires, it's a separate protocol from the hardware JTAG probe you describe.
First thing Intel would do is to implement/create new ME-like thing, maybe on other arch like ARK before and hide it little more.
Then finally someone would find it anyway in a few years and let others know about it ...
"History does not repeat itself, but it rhymes."
The article doesn't have many details though.