Slashdot Mirror
MINIX: Intel's Hidden In-chip Operating System (zdnet.com)
Steven J. Vaughan-Nichols, writing for ZDNet: Matthew Garrett, the well-known Linux and security developer who works for Google, explained recently that, "Intel chipsets for some years have included a Management Engine [ME], a small microprocessor that runs independently of the main CPU and operating system. Various pieces of software run on the ME, ranging from code to handle media DRM to an implementation of a TPM. AMT [Active Management Technology] is another piece of software running on the ME." [...] At a presentation at Embedded Linux Conference Europe, Ronald Minnich, a Google software engineer reported that systems using Intel chips that have AMT, are running MINIX. So, what's it doing in Intel chips? A lot. These processors are running a closed-source variation of the open-source MINIX 3. We don't know exactly what version or how it's been modified since we don't have the source code. In addition, thanks to Minnich and his fellow researchers' work, MINIX is running on three separate x86 cores on modern chips. There, it's running: TCP/IP networking stacks (4 and 6), file systems, drivers (disk, net, USB, mouse), web servers. MINIX also has access to your passwords. It can also reimage your computer's firmware even if it's powered off. Let me repeat that. If your computer is "off" but still plugged in, MINIX can still potentially change your computer's fundamental settings. And, for even more fun, it "can implement self-modifying code that can persist across power cycles." So, if an exploit happens here, even if you unplug your server in one last desperate attempt to save it, the attack will still be there waiting for you when you plug it back in. How? MINIX can do all this because it runs at a fundamentally lower level. [...] According to Minnich, "there are big giant holes that people can drive exploits through." He continued, "Are you scared yet? If you're not scared yet, maybe I didn't explain it very well, because I sure am scared." Also read: Andrew S. Tanenbaum's (a professor of Computer Science at Vrije Universiteit) open letter to Intel.
This stuff is overblown since these management engines are only ever active in a limited set of corporate environments where out-of-band management is a huge plus that actually improves security by not requiring your IT drone to physically access every system even if it's turned off.
Oh, and don't think your magical AMD saviours are any better. There a TrustZone processor that you have zero control over embedded in their products that does the exact same bad stuff.
AntiFA: An abbreviation for Anti First Amendment.
AMD PSP
Yes, it does. It's called "AMD Secure Processor" nowadays, but it's better known as PSP (as in "Platform Security Processor", its original name).
Because it is functioning as intended for its usage among authoritarian regimes (the US included thanks to Congress, the NSA, CIA, and domestic SigInt/PsyOps.)
The Clipper chip concept was never off the table its implementation just became less 'warrant and seize' and more 'illegal wiretap'.
Kids these days...
Andrew S. Tanenbaum is the original creator of MINIX, not just "a professor" at Vrije Universiteit.
1) Yes
2) Because shitty nerds decided it was an issue.
3) Intel doesn't need to recall anything. It is OFF by default.
I can't emphasize this enough, it's a non-story that affects absolutely nobody except for platforms used by enterprise (think business laptops for asset tracking)
The average person does not have the Management engine turned on, it's built into the PCH chipset, not the CPU. You can actually rip out the firmware for the IME from the BIOS if you're paranoid as hell.
From Wikipedia https://en.wikipedia.org/wiki/Intel_Active_Management_Technology :
"Although iAMT may be included for free in devices sold to the public and to small businesses, the full capabilities of iAMT, including encrypted remote access via a public key certificate and automatic remote device provisioning of unconfigured iAMT clients, are not accessible for free to the general public or to the direct owners of iAMT equipped devices. iAMT cannot be fully utilized to its maximum potential without purchasing additional software or management services from Intel or another 3rd party independent software vendor (ISV) or value added reseller (VAR)."
IPMI has been around for a longer time than this, and guess what, it's basically the same thing, and you haven't server managers screaming bloody murder over it, because it has to be turned on in the BIOS, and you have to have the operating system use the watchdog process to tell it that something's amiss.
Which is why nerds shitting their pants over this is rather amusing more than concerning. The difficulty in pulling off anything is exceptionally high, that the most likely targets are in fact enterprise systems, and the most likely people to exploit it are corporate spies, because if you can get "inside" the network physically, you can compromise anything connected by the network if the IME is enabled and poorly configured.
We have a couple facts here, and a whole bunch of conclusions.
The facts are that there is a general purpose OS running a microkernel in a management layer on unspecified Intel CPUs. This general purpose OS provides at least network accessible management interfaces.
The conclusions are this general purpose OS is infinitely exploitable to steal all your top secret information and redirect all you web requests to the mind control platform of the month.
This Minnich character (I enjoyed that similarity, Minnich/Minix) then jumps to a call to neuter everything below the user installed OS including UEFI. He then juts off on a side tangent and says trust me (He is a Google engineer) to always install good safe firmware on your Chromebook. That was a nice subtle bit of astroturfing there. He also blames Minix for slow boot time on an Open Compute server, not sure where minix plays into that or what axe he is grinding.
Let's look at it a little more objectively. Why do these processor companies keep putting general purpose OSs at a level which was traditionally all hardware/firmware, and why do systems makers use an accesible programming layer to configure hardware like UEFI? Well, whe we were running 386s and 486s we really were running microprocessors. Hardware was relatively static, device support was locked at time of manufacture, processors did processing (with maybe a coprocessor for math) and accessory cards did a single function each. In that time frame supers, like the first Crays, couldn't even boot themselves. They used a completely separate computer to boot and for time scheduling and such. Now today, we have computers which are powerful on the level of the early supers. Our processing no longer all happens on the CPU, but also in the GPU(s) and other pieces in the system. We no longer have external memory and bus controllers, they are built into the processor or the mandatory northbridge, and are much more capable and adaptive. There are hosts of sensors built into modern processors. All of these pieces need to be managed. There is an absolute necessity for a relatively capable computer in there to manage all these pieces.
It used to be done with static logic arrays, controlled by registers, and we called it BIOS, and it had a little interface that could usurp the monitor output and keybpoard and chirp the speaker, later got so fancy it could hijack a mouse on some systems. It was very limited, in fact, on the earliest PCs it didn't have a UI at all, it had dip switches or jumpers on the system board.
Now with the advent of negotiated buses (even memory buses, back in the day I never would have conceived of a CPU being able to ask a memory module what capabilities it possessed and automatically configure timing parameters to best talk to it) the management processor has a lot to do. On high end machines they even do this negotiation on the fly with the advent of hot plug PCI buses and on the fly memory error compensation. By the nature of the beast this management engine has to be able to see all the data buses, otherwise every single connection interface would need an out of band management channel.
I suppose you could make this management engine like a FPGA, configure it once and burn your bridges, no further interraction possible, but then what happens when you need to add or change something?
Likewise it often doesn't need a network interface, but if it doesn't have one then we have to do wake on LAN with yet another baby management computer. How about physical intrusion detection? again, not often needed, but sometimes...
Basically what a general purpose OS in the management layer does is give nearly infinite flexibility. This technology is a big part of the reason so much of our stuff just works.
Now, I am not really a drink the cool-aid from the benevolent overlords kind of guy, I am not at all in favor of secret OSs underpinning our hardware without our knowledge, but let's not throw out the baby too. That capability is in most cases useful
"Proximity to wonder has blunted our perception and appreciation of it" --Tim Hartnell in 'Exploring ARTIFICIAL INTELLI
Due to a 'bug' in the code, you can access the AMT with a zero length password. The ME cannot be completely removed, but due to a request from the NSA, it can be disabled with a secret kill switch.
For someone to get anywhere with AMT / vPro, they would already have exploited far easier routes to getting anything they could get through AMT / vPro. This is the reason we have seen exactly zero articles about people being exploited in the wild through AMT / vPro
NSA shill detected.
The hijacking flaw that lurked in Intel chips is worse than anyone thought
A query of the Shodan security search engine found over 8,500 systems with the AMT interface exposed to the Internet, with over 2,000 in the United States alone.