Can someone explain like I have a degree in computer science from a good university, but opted for a career as a software engineer in some relatively high level languages?
A JTAG is a standard minimal serial port used for debugging purposes. You'll find them on nearly all embedded devices - routers, phones, TVs, refrigerator controllers... usually appearing as a set of two or three contact points. Sometimes they connect directly to a debugger.
In this case, it appears that at least some Intel CPUs have a JTAG on the ME that can be routed through the on-CPU USB handler, and thus physical access to the right USB ports can be used to access the ME.
I suspect they fiddled with something to get access, however. Attached something to motherboard or similar.
Intel ME can be controlled remotely if you have an Intel lan card, even if the main cpu is off, but the motherboard is powered on. It goes from there and gets worse is my understanding.
[1]: http://www.amd.com/en-us/innovations/software-technologies/s...
AMD have something similar so no help there.
It's probably worse for AMD. For Intel now at least we'll probably get the ability to securely disable everything below ring -1.
AMD had the chance to differentiate from Intel here, instead they blindly immitate the same customer-hostile stunt.
And the AMD people now thinking hard how they can leak hints to their kill-switch in an inconspicuous way, too.
But that's indeed imagination. Unforunately, we don't (yet) know much about their motivations.
Intel decided it wanted a piece of that pie, and in an effort to improve margins, and sell more CPUs, Intel thought: "what if we offer the same feature, but use less hardware?" and made it part of their chipset.
As a feature that businesses actually want, and they buy CPUs in the 10,000's/year, compared to maybe 1/year I might buy for personal use. AMD implemented similar in order to keep up and remain competitive in the market.
Intel desktop chipsets aren't wholly different from their server chipsets, and they share some internals. Intel also realized that, since they already paid for development of the technology that it would be useful for administrators of a computer lab to be able to have remote admin access, and made it a requisite part of all systems.
Again, AMD implemented the same to keep up.
It could also be part of an NSA plot (it is part of their mission, after all), but "the market" where individuals don't count as much as corporate buyers, is sufficient to explain the situation.
There are some obvious reasons why it's not completely open, notably that ME enables feature unlocking keys and DRM at a lower cost than more hardware-involved approaches; but I don't think that explains the recent PR attempts and complete dodging of this issue.
Have you worked in large enterprise organizations that sold things to other large enterprise organizations? Did you go read the bit about how banks were pressuring Intel to include full blown JVMs into the ME and they resisted that?
> leaves a lot of crucial ethical and technical questions completely unanswered.
The truth is mundane which is that Intel wanted money from Banks, and a bunch of workers tried to split the difference between giving the Banks everything they wanted and trying not to engineer gaping security holes. They were operating with imperfect information and got that equation wrong.
And the truth is that no company in the world attempts to engineer for perfect security. When security runs up against economic concerns they try to balance the costs and benefits.
Assume that we (you the reader) can know perfectly which possible vulnerabilities are actually exploitable and which are not. If Intel spends any time on possible vulnerabilities which in practice are not exploitable or never exploitable, that is entirely wasted time. If AMD spends no time at all on those, AMD can focus on shipping features and get ahead of Intel doing useful work. Since Intel and AMD cannot have perfect information, they make guesses as to the impact of possible security holes. That naturally will always result in them "cutting corners" from the perspective of someone who measures them only on their security posture. Enterprise corporations like this are a complicated non-linear non-convex optimization algorithm that attempts to balance economic, security and other concerns against a complicated and shifting landscape in the face of imperfect information. Any company that tried to have always perfect security would largely fail in the marketplace.
This is related to the explanation of why the locks on the front door of your house or apartment can likely easily be picked.
Security concerns are sacrificed for economic concerns, commonly, everywhere around you.
Is it too costly to build a separate non-remote CPU for non-enterprise? Does it provide some useful functionality for regular consumers?
The answer is probably they do not think there's a market for it, but still makes me wonder.
Loads of us (sysadmins) complained that IPMI (DRAC, LOM...) had frequent security issues, wasn't running open-source code that we could inspect, and kept growing new features without any sense of responsibility. We were especially irked when a dedicated IPMI ethernet port got shared with a micro switch to a normal system ethernet port, and it was not possible to turn that behavior off.
Don't say we didn't complain. Say that we were not successful in having motherboard manufacturers implement the features we want in a secure and controllable manner.
If you want to compete with Intel or AMD in the CPU market, you are talking tens of billions in NRE before you ever have something that is remotely competitive. And then you have to do it all over when we switch from 14nm to 7nm, and then again when we go from 7nm to 3nm.
If you want more competition, you have to level the playing field by banning most of the op-codes. But even then you still have crazy amounts of pipelining and other optimizations which are nontrivial to figure out and very expensive to implement.
Intel is in a great position.
I'm pretty sure that i.MX6 chips are relatively clean. Modern chips are becoming less so.
So they can mess with ME (dump its code, analyze it, observe how it runs, modify it live) as they see fit.
"Towards (reasonably) trustworthy x86 laptops"
https://media.ccc.de/v/32c3-7352-towards_reasonably_trustwor...
Also, the paper by the author is worth a read:
"State considered harmful - A proposal for a stateless laptop"
https://blog.invisiblethings.org/papers/2015/state_harmful.p...
Imagine that you have your high level program. When you execute it, it goes through a just-in-time compilation (whether that's script parsing or bytecode conversion, or actual compilation, or whatever) before reaching the CPU which actually executes your code. Now imagine that your interpreter has the capability of reading and monitoring everything you do.
Nothing wrong with that, it's supposed to do that, it's how it works. But imagine if it had an exposed, unlogged, unmonitored, API which allowed a third party to be able to interact with whatever you do. Say that it's there "for debugging purposes".
You want to encrypt an HTTPS session? This API allows them to grab your key without ever notifying you. Or, even if you use custom encryption, it allows them to grab your specific instructions and the data used in processing to reverse your encryption.
It allows a remote party to inject their own flow of execution into your program. So you're sitting there waiting for the next user event to occur in your event loop while, instead, the interpreter simply handed the whole event loop to a third party. They could inject user events for you to process that the user never actually performed; they could modify data in ways that you can never detect.
Except that it's not the interpreter. It's a side-channel, an additional hidden core on your CPU (it's actually a completely hidden and separate secondary CPU). Your processor still runs and executes your code. But another processor is simultaneously running and executing its own code with its own RAM that you can't access. It has access to your RAM as if it were a file open on your hard disk.
You can't disable it. You can't interact with it. It's even running when your computer is "shut off". If there's power on the motherboard, then this hidden processor is running.
That, in a nutshell, is Intel ME...
... This sounds _really_ paranoid and alarmist. But it's not all bad. Intel has usually done really well with "security through obscurity" in this case and there aren't many known exploits for Intel ME. That said, those that do or could exist, gain all of the capabilities of Intel ME.
Most people consider "game over" for physical access anyway, so I'm not sure that pwning it with physical access is a new problem; instead it's a secret basement in a bank; it's only a problem if someone figures out it's there and starts digging a tunnel to it.
Also, remember that a lot of motherboards these days come with built-in wifi or bluetooth adaptors. Intel ME has access to those too; you can't just rely on an upstream firewall for your physical ethernet. With the right (wrong?) exploit, all it takes is an adversary to be within directional antenna distance (which is actually really far) to be able to pwn your system. The best way to prevent abuse over that channel is to physically break the antenna connection (lol warranty voided because you've damaged your motherboard).
Thanks for your helpful explanation. This bit sounds particularly bad - is the really possible in practice or just theoretical? Is there any source that has shown this?
* it's definitely possible for Intel (and anyone Intel gives access to) * it's theoretically possible for anyone with a zero-day hack (or now physical access)