Linked by Thom Holwerda on Sun 4th Jan 2015 14:22 UTC
Intel

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.

Order by: Score:
Comment by ssokolow
by ssokolow on Sun 4th Jan 2015 14:49 UTC
ssokolow
Member since:
2010-01-21

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

Reply Score: 8

Huh?
by Carewolf on Sun 4th Jan 2015 15:27 UTC
Carewolf
Member since:
2005-09-08

Is there a story or link somewhere besides the references, or is it just the quote?

Reply Score: 2

RE: Huh?
by ssokolow on Sun 4th Jan 2015 15:47 UTC in reply to "Huh?"
ssokolow Member since:
2010-01-21

It's linked from the Twitter post referenced.

http://www.alexrad.me/discourse/why-rosyna-cant-take-a-movie-screen...

Reply Score: 4

RE[2]: Huh?
by Alfman on Sun 4th Jan 2015 16:59 UTC in reply to "RE: Huh?"
Alfman Member since:
2011-01-28

These slides (referenced from the article) are much more technical and interesting:

https://ruxconbreakpoint.com/assets/2014/slides/bpx-Breakpoint%2...

Reply Score: 6

RE[3]: Huh?
by jockm on Mon 5th Jan 2015 16:27 UTC in reply to "RE[2]: Huh?"
jockm Member since:
2012-12-22

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

Reply Score: 4

The real Rosyna
by sj87 on Sun 4th Jan 2015 19:14 UTC
sj87
Member since:
2007-12-16

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.

Reply Score: 4

Closed firmware as a security risk
by chithanh on Mon 5th Jan 2015 17:24 UTC
chithanh
Member since:
2006-06-18

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.

Reply Score: 4

Alfman Member since:
2011-01-28

chithanh,

Here's how you install a keylogger and run it on a 2010 ME's ARC4


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.

Reply Score: 2