Slashdot Mirror
The Trouble With Intel's Management Engine (hackaday.com)
szczys writes: You've used many devices that have Intel's Management Engine built into them, even if you haven't heard of it before. This is the lowest level of security, built directly into the chips. But obscurity is part of its security and part of its weakness. Nobody knows exactly how ME works, yet it includes a wide range of features that would be frightening if exploited. The ME is always listening, able to receive packets even when the device is asleep. And it has the lowest level of access to every part of the computer system.
Stopped reading the conspiracy rant after this delicious gem:
Yeah, so because they finally abandoned BIOS, modern computers are suddenly insecure. With the implication that BIOS was somehow secure. Yeah, bullshit.
I'm not even saying that the IME is necessarily perfect, but conspiracy-theory drivel doesn't do much for me. That goes double for when it seems to be directed at one vendor and one vendor only while pretending that everybody else out there (AMD [which flat-out embeds an ARM processor in its parts to copy the functionality of IME], anything running ARM, etc.) is all magically secure.
AntiFA: An abbreviation for Anti First Amendment.
Between lack of a useful setup routine, centralized management, etc.. it's a royal PITA to actually work with on an Enterprise level.. It's nice though.. I'll give them that.. onboard VNC for BIOS level control like a DRAC/BMC/ORA/iLO, etc and ability to send WOL to PC level hardware is nice for those pesky users that have totally messed things up.. It's also useful for remote rebuilding of machines since you can remote redirect ISOs and such..
But.. again.. royal PITA to setup and the documentation is scattered and horrible to read through.
What do you mean "if"?
https://en.wikipedia.org/wiki/Intel_Active_Management_Technology#Known_vulnerabilities_and_exploits
Please provide a link to the documentation.
Sent from my ASR33 using ASCII
always listening, able to receive packets even when the device is asleep
When was the last time you saw a computer that didn't have "wake on lan", "wake on keyboard", and "wake on network"? It's not done by magic and pixie dust/
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
AMD calls their version of the IME the "Platform Security Processor (PSP)".
One of the side effects is that open source BIOS projects are effectively dead for desktops.
I read the internet for the articles.
If you don't like this sort of thing, buy devices that support Coreboot.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
Their closed approach probably stems from them getting a bit burned on IPMI. Intel was chiefly responsible for the spec, but the first real mass market servers that had it were AMD (mainly because of Intel's preoccupation with Itanium at the time). In the server business, Intel has nearl 0% share for service processors (third parties rule that roost, excepting the fact they all must interact with IME too). As they have evolved IME, they've kept it a tight restrictive secret. This means that the functionality is restricted to Intel based systems, but the tools to use it are crap and/or buried inside third party UEFI/BMC firmware.
Basically the industry as a whole had a moment of 'weakness' in the late 90s/early 2000s and had useful interoperable standards come out (not perfect, but serviceable and practical, IPMI and the various IETF SNMP mibs that came out around then). The big players have largely spent the time since trying to bury those standards and re-establish the previous status quo of lock in but 'standards' (looking at CIM/WS-MAN/SMASH/Redfish and Netconf, all of which emphasize vendor 'flexibility' to the point of rendering cross-vendor management with a single codepath impossible). A shame since there are issues in the old protocols that could use some fixing/enhancement.
XML is like violence. If it doesn't solve the problem, use more.
I'll give you an example of how ME is used on very common business-oriented cheap desktops like Dell OptiPlex or old HP dc series.
It all begun around the era of Core2Duo when manufacturers started to implement ME/AMT management solutions on their cheap office PCs. In the *default configuration* the access to ME's setup is unrestricted and protected by default credentials of admin/admin. Even if you have set a password on the BIOS itself you can still enter ME setup by just pressing a hotkey during boot.
Since ME has a full-blown TCP stack it can even listen on a separate IP that can be set in the ME setup. When configured you basically own the PC, you can control power, attach IDE/CD/FDD images and remotely boot from them. If the current graphics mode is ol'DOS you can even redirect that on the Serial-Over-LAN interface without even having the full AMT (which uses VNC to redirect any graphics mode). All that is done over super-secure SOAP with no encryption by default.
If your manufacturer was competent there probably is a burried update to make it DASH-compliant and to make it not accessible without the BIOS password.
What is more it's possible to attack ME/AMT remotely with broadcasts to make it configure itself to open wide up. All you need is a certificate that's trusted, which is really not that hard.
It also has pretty neat capabilities to even filter packets in hardware, without the OS control!
Now for the intended purpose: different versions of ME/AMT behave differently in the desktop world. Missing features between generations, bugged features, broken power management. The default behaviour of taking 2 TCP ports for hosting websites that can be used to remotely control the PC itself is bad enough.
The firmware itself was confirmed by Intel to have unrestricted DMA, which pretty much can defeat any protections in software. The only way to stop it for sure is to use a dedicated NIC...
Software and APIs are really bad as well, the SDK is a collection of bolted-on turds.
It's all pretty sad really. And don't get me started on how it's implemented on laptops...
The PSP is nothing like IME. IME is a dedicated chip for remote management, which you can't touch.
PSP is simply a separate ARM core that you can control, including running a separate OS. The PSP ARM core, in turn, has a common ARM feature called TrustZone, which provides very strong security guarantees for the software running inside the TrustZone. Again, you control how this is configured and what software runs in the TrustZone.
I don't know about the PSP specifically, but most ARM chips with TrustZone also support something called HAB (High Assurance Boot), which is basically a secure boot mechanism like TPM. It allows you to set a public key used to verify the boot image, and using e-fuses you can programmatically make the public key immutable.
But ARM chips almost always come without any firmware pre-configured. The whole thing is a clean slate. The intention is for people (usually companies) to build their own special-purpose applications using these capabilities, and usages very widely.
IME, by contrast, is just pure evil. If you're lucky, the IME controller is only tied into a particular NIC, in which case you should make sure to _never_ plug anything into that NIC--perhaps fill it with glue. That doesn't solve all the issues--theoretically an attacker could tickle bugs in the IME purely from running in user space on the main CPU--but it closes a huge security hole. Yes, attackers have remotely broken into servers via IME, in some cases just by using the default passwords.