Given that the ME sits in a position where it can configure the chipset and operate on the PCI bus, there are some serious security implications here I wish I could mitigate. Among them is the ability of the ME to run arbitrary code on the host CPU via option ROMs or presenting a disk-drive to boot from. Also among those abilities is the possibility to perform DMA to access host CPU memory. And another one is the ability to configure and use PCI devices present in the system (such as the ethernet card).
As a consumer, I didn’t ask for these features. It’d be great to turn them all off. A hardware switch even. And BIOS settings do have a way to “Disable” the ME. But is it truly disabled? It will still run some code at startup I assume. And given that the Intel ME’s security model requires that the host CPU is less privileged than the Intel ME, how can the host CPU really turn it off? One example of how the ME is more privileged is the ability to walk around VT-d configuration when performing memory access, which is possibly something required to make PAVP secure.
Baseband processors, FireWire, Apple’s Thunderbolt, IME – you may think your operating system is secure, and even if that were true (it isn’t), there’s still dozens of little pieces of firmware in every machine you own – from your smartwatch to your car – which are closed off, impenetrable black boxes of crappy, insecure code.
As for who or what ‘Rosyna’ is – I think she or he is a person the author knows. Took me a little while to figure that one out (I thought it was a computer program at first). Not really relevant to the story at hand, but I figured I’d save you the confusion.
This is one of many reasons why I bought AMD last time, even though Intel had better offerings. Last I heard, AMD was still using optional, off-die management technologies.
(And why my only portable devices are an OpenPandora and a Sony PRS-505 eReader)
Is there anyone out there cataloguing how much adoption the IOMMU has seen in the world of Linux drivers for DMA-capable components? (Sure, it won’t stop boot-time bypasses, but it’d narrow the vulnerability window)
Edited 2015-01-04 14:53 UTC
Is there a story or link somewhere besides the references, or is it just the quote?
It’s linked from the Twitter post referenced.
http://www.alexrad.me/discourse/why-rosyna-cant-take-a-movie-screen…
These slides (referenced from the article) are much more technical and interesting:
https://ruxconbreakpoint.com/assets/2014/slides/bpx-Breakpoint%2…
Thanks for pointing that out, very interesting stuff. One especially interesting tidbit is that on BayTrail systems the ME is SPARC (v8) based!
My guess is that is based on the LEON* — a [L]GPL implementation of SPARCv8 designed by the European Space Agency — but I suppose it is possible Intel could have implemented/improved it. They do know a few things about CPUs.
I got to program one (a LEON, not a ME) on a project once and found it a pleasingly powerful, so it is always nice to see it pop up here and there.
*: http://en.wikipedia.org/wiki/LEON
Rosyna is referenced in the sources. Maybe it was added after OSnews published its own writing, but now there’s a straight-forward reference to the inspiration for the original article.
The good news is that the Intel ME/AMT is not very suitable as a malware target, as the code needs to be somewhat specific to the AMT revision. Also it is difficult to attack from outside the local network. Much easier targets exist (browser, Flash, etc.).
The bad news is that setting the AMT option to “disabled” in your BIOS might not actually disable it fully or during early boot.
Here’s how you install a keylogger and run it on a 2010 ME’s ARC4: http://dl.acm.org/citation.cfm?id=1866307.1866381 (Executive summary: http://www.isti.tu-berlin.de/fileadmin/fg214/patrickx/InGodWeTrustA… )
If you happen to know about vulnerabilities in the targeted revision of AMT then you can even do it remotely and almost undetectably.
chithanh,
Thanks for pointing it out! Didn’t read the article behind the pay wall, but it seems like there is indeed an extremely high risk. I always thought x86 “system management mode” was dangerous, but this “management engine” is even more so.
I do actually like the control features IME offers. But it needs to be open source and users need a way to verify the code that this processor is running, otherwise it’s ripe for exploitation by malicious third parties.