Game Over We Have Obtained Fully Functional JTAG for Intel CSME via USB DCI | Hacker News Reader

Game Over We Have Obtained Fully Functional JTAG for Intel CSME via USB DCI

twitter.com

291 pointspanny58 comments

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.

No. Apple, and perhaps other manufacturers, insist it not be there.

> 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"?

Subjunctive

Thanks. Additionally, I must have misread the not for a no.

Are you saying that the only, readily available, modern x86_64 system without this crap (or AMD equivalent - or Apple equivalent) is a mac?

Any sources for IME being completely disabled / not present on macs?

It's not disabled.

Apple uses a minimal ME firmware, but it's still 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]

[0]https://www.theregister.co.uk/2017/08/29/intel_management_en...

Have a look at https://www.theregister.co.uk/2017/05/01/intel_amt_me_vulner... - it seems the Active Management Technology platform firmware module isn't deployed at all on Macs

> It's really puzzling that Intel would risk the entire company to include features like this.

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.

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?

It's common to be able to run a remote debugger via JTAG, allowing the system to run normally, set breakpoints, examine memory, etc.

Even though it's run over the same wires, it's a separate protocol from the hardware JTAG probe you describe.

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 ...

"History does not repeat itself, but it rhymes."

Found this older article informative as background :

https://www.digitaltrends.com/computing/intel-kaby-lake-skyl...

Because it took a while to find - here is the actual talk they are referring to : https://media.ccc.de/v/33c3-8069-tapping_into_the_core

Can anyone explain what this means?

JTAG is used as a debug interface, so the implication is that full access to intels AMT (where minix3 is said to be running) has been achieved

Can you explain what this means?

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?

Precisely so. At least for the Intel machines that have IME features. So all the enterprise, data-center boxes but not every laptop.

Edit: I read some more. It looks like this is going beyond what I thought and affects way more machines.

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.

Then you simply have to replace the bios with one that has USB debugging enabled. Or change registers on a working machine

‘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.

i mean to resolder the flash chip that holds it

Given what we know of the NSA's past predation, why would one think this is not intentional?

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.

[1] https://security-center.intel.com/advisory.aspx?intelid=INTE...

This link is broken.

They probably removed the languageid parameter, thinking it was optional.

https://security-center.intel.com/advisory.aspx?intelid=INTE...

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.

Excellent, where can I trade in my ducky for this upgraded version?

With physical access to a machine’s USB 3 port, someone could insert running code beneith the operating system, and it wouldn’t know.

You could spy on user activity, sniff encryption keys etc

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.

Sorry, I’m not sure, this stuff largely goes over my head. I just understand the basics.

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.

All your CPU are belong to us

it means you can get remotely hacked by someone controlling cheap gadget manufacturing, something like this:

http://www.tomshardware.com/news/mantistek-gk2-collects-type...

but invisible and undetectable

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.

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.

A single screenshot with no accompanying explanation? Is there a clearer indicaton of contempt for the readers?

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.

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.

The computer isn't off; the NIC is still on and it can wake the rest of the system. https://en.wikipedia.org/wiki/Wake-on-LAN

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.

It doesn't need to be a wired network: https://software.intel.com/en-us/articles/technical-consider...

If anyone is interested, there is an article about this in russian (Google-translated): https://translate.google.com/translate?sl=ru&tl=en&js=y&prev...

The article doesn't have many details though.

blog post with more details from the tweet's author: http://blog.ptsecurity.com/2017/10/how-to-obtaining-full-sys...

This should be good for the TalosII workstation orders: https://secure.raptorcs.com/content/TL2WK2/purchase.html

I wonder if it'll work over WebUSB...

Fucking horrifying.

No, that's the host side of the equation, and I don't think WebUSB will ever do Gadget emulation.

I can see use-cases for it, but good luck convincing the W3C.

What about Bluetooth and Wi-Fi...

Worse than rooting the computer. A JTAG debugger has chipset-level access to a system. Likely that nothing is detected in the operating system.

Intel has put CSME and DCI in all (?) their chips since 2015. Skylake was announced in 2014, launched in 2015.

Good. Maybe results like this will increase the pressure on Intel to make this garbage disableable.

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.

Reply on news.ycombinator.com