Intel and ME, and why we should get rid of ME
fsf.org
fsf.org
Intel has a jolly video demoing how to pwn a machine remotely (framed in the positive light of taking control and fixing a boot problem by the it service desk):
http://www.intel.com/content/www/us/en/remote-support/remote...
This is for 6th generation+ cpus, but the systems in older cpus are also quite powerful. And can't really be protected beyond using a password/passphrase. I'm not sure (and probably no-one knows) if there's also a golden key/backdoor.
(I wonder if the video is actually narrated by Zach Woods (Donald 'Jared' Dunn from Silicon Valley) - or if it just sounds a bit like that).
At any rate, if watching that jolly video doesn't fill you with fear, I'd say you're not sufficiently paranoid.
https://software.intel.com/en-us/forums/intel-business-clien...
Plus, even you disable it there's still room for exploits, previous versions of Intel AMT have had exploits. Check out the 'Known vulnerabilities and exploits' section of the Intel AMT Wikipedia page:
https://en.m.wikipedia.org/wiki/Intel_Active_Management_Tech...
Maybe it's the server admin in me, but OOB BIOS-level remote access and management for my systems is a godsend and my biggest issue with it is that they tend not to include those features in their "enthusiast" chipsets.
As for the number of people who think remote access is bad, nobody seems to be denying it can be useful, but by baking it into hardware you're basically hoping that it doesn't get hacked. If it was an optional dongle nobody would care.
Optional, hardware mediated remote access is good.
There is a common misunderstanding in these discussions that the ME features of the Intel processor (included in nearly all modern procs) allows for hardware level remote access, which isn't true.
[1] https://en.wikipedia.org/wiki/Intel_Active_Management_Techno... [2] https://en.wikipedia.org/wiki/Intel_vPro
It really wouldn't be that hard to compare what you received from the foundry with the masks you sent them. There are services that decap ICs and attempt to reverse engineer them. Here's the first hit I found on Google: http://www.intelligservices.com/Services.htm
You wouldn't need the reverse engineering. All you would need to do is to compare that all the metal layers (and perhaps poly) match what you sent. That's an almost trivial comparison. The hard part of reverse engineering is in figuring out what the circuitry actually does, and you already know that, since it's your chip!
It could be possible for a fab to alter diffusion layers to change the functionality of a chip. That would be harder to detect by services such as the one I mentioned. But it would be very hard, very time consuming, to attempt to hack in a backdoor by only messing with base layers, rather than messing with metal or with poly (where changes are easily observed).
If there were to be a backdoor anywhere in a design, it would be in IP you used on your chip, that you got from either your foundry or from a 3rd party IP supplier. It would be easy enough to hide all kinds of stuff there.
To put it another way, what are some of the details that the author(s) of this article got wrong?
Nearly everyone reading this on a laptop/desktop system is doing so on an Intel processor. Go ahead and attempt to enable remote access without a supported proc/chipset/bios and then come back and complain about this unexpected remote access.
There is a lot of misunderstanding about this technology in the security world which strikes me odd because it's well-documented and readily available for your own testing.
As for trust, first, what we generally know is that any complex system is likely to have flaws. So any remote access system is likely a back door - intentionally or not. A physical off switch would be prudent (arguably switching off wireless network card and not connecting an ethernet cable is one option: but then your options are: no networking or possible vulnerability).
It's not as if any networked machine is "perfectly secure" - but it'd be nice to be able to set the scope of exposure even more easily, and granularly.
Second, one thing is trusting Intel to not intentionally install a back-door - keeping in mind that includes any "golden key" for updates. And not leaving any holes in the interface they expose (ie:getting the feature right). That in itself is a pretty high bar, imnho. But another thing is trusting Intel not to build in secret backdoors - that is; if they say, no, there's no IME in product X, then trust them on that. That is to me a much more trivial thing to trust. I know there will be bugs in the software and hardware, but I'm not all that afraid of maliciousness.
If I was working for a Chinese intelligence service the threat model might have been different.
In sum, given that there's bound to be bugs, and might be well-intentioned software upgrade support - I would prefer if it was easier to buy high-end parts without stuff like IME (this also applies to AMD btw) - or at least that it was easy to remove a jumper or toggle a dip switch to turn the stuff completely off.
[ed: finally re: server Vs laptop: there are some things that doesn't matter as much if it's exposed on a server: got my encrypted backups? Encrypted email? No problem. Got my secret key from my laptop? that is a problem]
The usual recommendation is to either get a pre-2009 AMD machine (which is what my present desktop is) or get a Sparc machine. My boss won't buy me a desktop with an UltraSparc CPU, so I won't bother with that. AMD has substantially less documentation than Intel, AFAICT, so Intel products deserve investigation for their relative starkness.
An albeit outdate list of systems to avoid, see [1].
I will assume that you are trying to build a desktop from off-the-shelf parts.
For sure, get a CPU without vPro, since that downgrades the type of AMT/IME feature set to Standard Manageability:
"Please note that NON -vPro™ Intel® desktop procesors will make Intel® ME FW to switch its features set from full Intel® Active Management Technology to Intel® Standard Manageability that do not suport Intel® AMT KVM Redirection feature (it is disabled internally in the Intel® ME FW)." [2] When the CPU doesn't support AMT, then Standard Manageability is what is running in the background.
This says 2 things: (1) non-vPro desktop CPUs downgrade AMT to Standard Manageability and (2) IME is active regardless of the CPU's feature set.
What is Intel Standard Manageability? "Q8: What is Intel® Standard Manageability and can it run on a non-Intel® vPro™ technology-based CPU? A8: Some basic management capabilities are available on non-Intel® vPro™ technology-eligible Intel® Core™2 processors as well as Intel® Pentium® dual-core and Intel® Celeron® processor-based CPUs. Intel® Standard Manageability is available only on desktop systems right now (not notebook), and only includes basic capabilities such as hardware and software inventory and remote diagnostics." [3]
I can't tell if Standard Manageability is a lite version of AMT. Intel's documentation on it [4] isn't a whole lot of help.
Intel mentions that Atom and i3 platforms generally do not support AMT. [5]
At the bottom of this [6] page lists those Intel chipsets with IME. I'd consider that to be a list of chipsets to avoid, but those cover almost all modern chipsets, AFAIK.
For sure, don't use any Intel NICs: "Adding another NIC will not nullify Intel® vPro™ technology verification, but Intel® Active Management Technology communicates only through the onboard network interface of Intel vPro technology, and it is strongly recommended that an additional wired NIC is not added to the platform as this might cause some of the features of Intel AMT to not operate as expected." [7]
[0] = http://ark.intel.com/search/advanced?s=t&VProTechnology=fals...
[1] = https://communities.intel.com/docs/DOC-2033
[2] = https://communities.intel.com/thread/65350
[3] = https://software.intel.com/en-us/articles/intel-vpro-technol...
[4] = https://software.intel.com/en-us/blogs/2009/03/27/what-is-st...
[5] = http://www.intel.com/content/dam/www/public/us/en/include/re...
[6] = https://www.kernel.org/doc/Documentation/misc-devices/mei/me...
[7] = https://software.intel.com/en-us/articles/intel-vpro-technol...
I'd like to know what chipset to choose in the future.
Thanks.
https://duo.com/blog/out-of-box-exploitation-a-security-anal...
e.g. http://teletext.zaibatsutel.net/post/145370716258/deadupdate...
But you're totally fine that THESE are the people with unfetted power to fill your system with backdoors? (Not to mention NSA etc who'd almost certainly have access).
What's wrong with you having zero care about the world's data security?
I just don't understand why people are suddenly railing against IME instead of Dell, SuperMicro, HP, etc when there is far more hardware out there with far, far less secure BMCs and it's been that way for ages. IME is probably closer to the best of the bunch as far as security goes.
https://www.schneier.com/blog/archives/2013/01/the_eavesdrop... https://isc.sans.edu/diary/IPMI%3A+Hacking+servers+that+are+... http://arstechnica.com/security/2013/08/remote-admin-tool-im... https://www.usenix.org/system/files/conference/woot13/woot13... https://community.rapid7.com/community/metasploit/blog/2013/... https://www.schneier.com/blog/archives/2013/01/the_eavesdrop... http://www.websecuritywatch.com/authentication-bypass-vulner... http://fish2.com/ipmi/itrain.pdf
It's not that remote access is bad, it's that all the remote access I've seen has been horrible. Hash disclosure is just seen as "meh, that's the way it is", and being able to login without a password is standard unless the IT has taken the time to update something they often don't even know about.
http://blog.invisiblethings.org/papers/2015/x86_harmful.pdf http://blog.invisiblethings.org/2015/10/27/x86_harmful.html
Essential reading!!
Also, I would give anything for a clean slate design that prioritized simplicity and transparency.
We've been layering complicated crap under and on top of older complicated crap for so long that even professional engineers no longer understand exactly what happens when you push the power button.
As long as that is true, we will never be secure.
One of the extremely few people with genuine understanding of hardware security, who's working on the side of users & humanity.
The first time I read her work, I was floored that I hadn't known of her earlier.
Cherry-picked from that thread. I just have to point out this awful slippery-slope argument.
Basically Intel owns the desktop and server market. They sneak stuff in that we may not want. What can we do at this point?
With Google having ported all their software to Power8, I'm looking forward to more economies of scale kicking on.
I currently have a 125W TDP AMD processor with "just" 8 cores, looking forward to a Power8 workstation that should have 64 logical CPU cores at 130W TDP [1] and avoids the Intel ME/AMD PSP trap.
Unless the firmware running on the BMC is going to be open source, I fail to see how it helps.
Open-toolchain FPGAs
Blob-free operation
- Fully libre (open-source) IBM OPAL primary firmware w/ PetitBoot interface
- Fully libre (open-source) OpenBMC secondary (IPMI / OoBM) firmware
NO signing keys preventing firmware modificationThere are already Open Source CPU designs, but the verification is more difficult. Even if you use a big enough process node that you can decap it and inspect it optically (eg. using similar techniques as used with http://visual6502.org/ ), there is still the possibility of dopant-level backdoors which are much harder to detect:
Security is not a boolean. It's a price to own you. By removing Intel ME you increase this price.
BSD-licensed, cutting-edge architecture and it's got the right backers.
FreeBSD is already ported to it. There'll be a range silicon implementations. Cambridge's lowRISC is likely to be the first SoC, with design completing this year.
Anyway, here's an entirely open source one you can inspect: http://www.lowrisc.org/. Put it on an FPGA if you want.
As dandelion_lover says, security is not boolean.
I may or I may not trust Intel to backdoor the processor I run code of my choice on in more or less visible ways (the more visible, the more risk of public opinion backlash if it is revealed what Intel did), but I absolutely do not trust Intel and its business partners to design an independent subsystem that runs their code and is not vulnerable to Intel (or any rogue employee thereof) + Intel's business partners (or any rogue employee thereof) + US federal entities (or any rogue employee thereof) that can coerce any large or small US company.
I am not suspecting Intel of ill intent. I am suspecting Intel and its partners of incompetence. There is a big difference. Intel can not actually “backdoor the main CPU as easily as” they can leave the ME open to attacks. The second one is so easy that you might as well assume it is the case until convincing arguments have shown otherwise.
In some sense having Intel ME is worse than having Windows as your OS: at least you can apply security patches for Windows, and should you choose to do so you can replace it with your favourite OS. However Intel ME is entirely closed source and locked down: probably running out-of-date software with several unpatched vulnerabilities with no way for the user to inspect it, patch it, turn it off with a jumper or replace it.
The data can be manipulated there and then copied to another computer using... uh... a writeable compact disk? USB drives are hard to trust given how much software is running on them, so... maybe CF cards too?
Tin Foil Chat[1] has a circuit for an opto-isolator based data diode and a discussion of how to use them for secure chat. It's probably not hard to modify these plans for other uses, if the specific guarantees that TFC provides are compatible with your secure computing requirements.
Some security experts say air-gapping is not the best approach. Consider Qubes OS instead.
"How does Qubes OS compare to using a separate physical machine?", https://www.qubes-os.org/tour/
I'm sure Intel has a real good reason for it being there but I would feel much more comfortable with it either not being there or being able to disable it in hardware.
The ideal security mechanism would provide us with a per cpu key from Intel, which we use to update our own user key to the cpu, and only user signed firmware is loaded.
The exact mechanism of this can be handled in many ways.
Right now, we locked out, and primed for being snooped on without our consent.
I like Intel's engineering, but everything else I could do without.
And ARM is no better. I'd say worse actually, but I'm not going to defend that.
Please, please, AMD do the "right thing" with Zen. Allow us to be in command of our security, so we may delegate it to those we trust with the technical know how, be it OS vendors, or our IT departments, or our own selves.
Heck, just access the HD where you boot your OS from and reimage it.
--
¹ https://libreboot.org/faq/#intelme See paragraph 6.
² https://plus.google.com/+TheodoreTso/posts/SDcoemc9V3J
³ http://www.eteknix.com/expert-says-nsa-have-backdoors-built-...
⁴ http://www.infowars.com/intel-ceo-refuses-to-answer-question... (Note the NSA slide.)
⁵ https://www.reddit.com/r/IAmA/comments/1ycs5l/hi_reddit_im_b... (No hard evidence, but he dodged basically every question related to the NSA.)
Better citation needed. AFAIK the ME has never been used for DRM. It's supposedly used to implement TPM 2.0 aka PTT, but AFAIK that has never been used for DRM either.
https://www.slideshare.net/mobile/codeblue_jp/igor-skochinsk...
AFAICT Intel's desktop RAID tech literally just remaps PCI vendor and device ids (which is a wee bit more complicated with NVMe / AHCI over SATA Express). The boot process was an option ROM and is presumably now baked into UEFI. The driver does the rest.
I can imagine that a couple bits in ME tell the UEFI blob and the driver which feature set to enable. Is there more?
One of many implementations: http://www.upsidedowntext.com/
For example, having IPMI with serial console access or a full-fledged VNC on HP iLO on servers proved to be really useful on different occasions, where I was able to fix the boot-level problems remotely rather than having to drive for an hour to visit the server.
Remote access is of less importance with desktops - and even less with laptops - as in most cases user is physically present, but still I had a few cases where I regretted not having a way to remotely connect to my machine at home (it had failed after a power outage), while I was on the road.
I'd say, the very core idea isn't really bad. Intel's implementation is terrible.
But, sure, I fully agree about the need of such system being an open platform that user can audit, update and control - rather than a black box. (Well, if there is a platform at all - a simplest external IP KVM could be a very dumb hardware box with the only software being an extremely primitive TCP/IP stack.)
Added: Anecdote: In early 2000s, some company I know of, had quite simplest remote access tools - DIY remote reboot devices made of externally-powered Realtek network cards. Sending a WoL packet to a known MAC (on a well-isolated network) would forcibly power-cycle the connected machine or router. No amount of fancy software solutions would bring a well-hung host back online. ;)
Which Intel ME isn't any more than a hypervisor is. It uses the same CPU and network interface and can be misconfigured in the same ways a hypervisor can. It essentially is a hypervisor but one that you can't remove or replace.
There are advantages to really independent hardware but firmware doesn't get you those, and there are advantages to management software but none of them require the software to be burned into the silicon. I agree that the feature set can be useful, it just doesn't belong where they put it (and in that sense we may only be arguing past each other).
Wake on LAN is a 20th century technology that requires no other privileges to implement and can be access controlled via managed switches. Pretty much every hypervisor will allow you to turn on a VM, change its boot device order or boot PXE and can change BIOS/firmware settings on any platform with an API to do that.
That's the point. If all you need is the ability to power on the machine, why are you exposing any more than that to the network?
> Most platforms don't have a way to change BIOS or firmware settings, and if they do, it's via the BMC anyways.
And the party in control of that is Intel, so they could provide that API instead of IME.
Intel is the party in control, and Dell, and Supermicro, and HP, and....
IPMI is the API you're looking for, you can always just shut off the networking. But again, it's still done through the BMC. SOMETHING has to do it, and that something needs access independent of the OS and the rest of the system due to the nature of the settings you can change.
Also how is IME any different than providing an API? The api has to actually do something, how exactly do you propose to do that without something like IME?
Turning on a powered-off machine is the only thing that couldn't be done by a hypervisor.
Once the machine is turned on, a hypervisor should be able to do anything IME does by doing it the same way IME does it, as long as the hardware is sufficiently documented.
The part of IME that is unnecessary is the software, because it's software in lieu of transparency and documentation. A separate management processor that you could install your own software on would not be a problem, and then you could even turn on the machine.
That could all be implemented, but it would require another hardware controller or some sort of api that has lower level hardware access than the OS does, and something to actually provide that access and communicate with the various components, at which point you just invented IME/BMCs.
Edit:
>The part of IME that is unnecessary is the software, because it's software in lieu of transparency and documentation. A separate management processor that you could install your own software on would not be a problem, and then you could even turn on the machine.
I suppose I can agree with that, and that's basically what most BMCs are, though installing your own software is hit or miss. (I've read about someone that got a stripped down linux kernel+userspace running directly on a SM BMC once) , Intel just moved it into the cpu.
IME just seems like a strange hill to die on when it's probably more secure than 90% of the remote management setups in use today, yet everyone seems perfectly ok with those.
What you've really invented is hardware drivers, which have been at home in the OS forever.
> IME just seems like a strange hill to die on when it's probably more secure than 90% of the remote management setups in use today.
The problem is they put it everywhere instead of only where people asked for it. You can get away with more on something which is opt in because the people who don't like it can get the one without it. So now it doesn't have to be as secure as the other remote management setups, it has to be as secure as not having remote management.
Those drivers need to actually communicate with something though, that something is exactly what BMCs are. If the hardware physically providing communication with those systems isn't there, no amount of drivers will help. Additionally, many of those things have to be configured before the OS is loaded and the hardware they control is fully initialized. Not possible inside the OS.
>The problem is they put it everywhere instead of only where people asked for it. You can get away with more on something which is opt in because the people who don't like it can get the one without it. So now it doesn't have to be as secure as the other remote management setups, it has to be as secure as not having remote management.
Yeah, I guess that's an aspect I didn't think of. I can see why people wouldn't be happy running remote management on their consumer hardware, I guess my view is biased by the fact that on systems I frequently work with, having a BMC is a given. My only experience with IME in consumer-level hardware was a neutered version of it where remote access wasn't an option, just some local hardware monitoring/management that seemed mostly useless, but I guess that must've changed.
You're going to have a chicken and egg situation at boot. The SATA/SAS HBA needs some code to read the OS with, but in a sense this is just a piece of your OS that has to be installed on the HBA, in the same way as grub has to be installed in the boot partition. Once the OS is running it can load different code into the HBA or replace the code that will run on the next boot.
We can argue about whether to call that sort of code a BMC or not but the more important question is if people can replace it or not, so that people can fix things the manufacturer doesn't.
Intel needs to give us an alternative.
Doubt that will change anything (willingness, price for probably new masks etc. etc.) but it would certainly be nice.
Is this laptop the top of the line spec-wise that you can buy which is free from this trash?
Which means that while this is nice and all, I got crap to be doing.
It already takes Visual Studio 3 hours to "repair" itself once a month when it stops working, and that's on a machine that would have been a supercomputer in 2008.
If someone comes out with an ARM64 Chromebook in the near future, that might be a good device to target for fully-free system efforts.
While the laptop situation is indeed pretty bad (the X200 is probably as best as you can get here), for people looking for a modern workstation, AMD's current FX processor lineup is still free from this trash. Past the 2013 designs (Family 16h [1]) AMD includes their own equivalent of Intel's ME called PSP [2], so presumably the upcoming Zen is going to be heavily backdoored too.
Now, you can still buy an 8-core/4 GHz+ AMD Vishera [3] generation (which is the "current" FX), add a motherboard with ECC support (in a stark contrast to Intel, all AMD FX processors fully support ECC memory and for example ASUS sells a number of AMD motherboards with ECC support) and build yourself a workstation that will easily last for another decade, possibly longer (you can always buy a motherboard or two of your favourite model as a backup for the times when they finally disappear from the market). All FX processors are factory unlocked [4] and can be pushed much farther past their design specs with decent cooling, adding another bit to their possible usefulness over the long term.
Some more (random) reading on the subject of avoiding AMD PSP and Intel ME:
http://hollaforums.com/thread/557954/technology/uncorrectabl...
-
[1] - https://en.wikipedia.org/wiki/List_of_AMD_CPU_microarchitect...
[2] - https://libreboot.org/faq/#amd
[3] - https://en.wikipedia.org/wiki/List_of_AMD_FX_microprocessors...
[4] - http://www.techpowerup.com/153445/amd-unlocked-fx-processors...
(Heavily invested in Rockchip/MediaTek chipsets. Less scared of chinese backdoors than FIVE EYES backdoors.)
To explain further, here's a comment I made about this before...
But be assured every thing is fine since for security reasons you cannot see their code.
I can enter into it but its vital parts are password protected. Even though it is my computer, I cannot configure and control it. Scary. This is not the future I wanted.
Firmware level ME features are usually found on the 'enterprise' grade laptops, OS driver support for ME is another issue since that can usually be taken advantage off regardless of firmware support but it requires additional software.
But I might be wrong. For example this 2008 year document [1] says it uses same IP and MAC address as OS and filters packets by port number.
[1] http://web.archive.org/web/20080219044745/http://softwarecom...
If we assume Intel is malicious, they hardly need a platform like ME to do harm. And isn't this kind of stuff only available on the more expensive systems? Because they include this to sell to enterprise help desks, right?
I dislike articles that seem set to spin something. At least explain the plausible or documented reasons, then show why it's bad.
ME & AMT have become common on consumer gear, laptops, etc. and Intel chip, chipset & nics are a common combination.
The attack surface is also huge for anyone intent on compromising it.
Of course in practice, as long as say Linux runs on the machine, the existence of the ME or the like is almost inconsequential for the user, because you run the same software, and there's never a shortage of security vulnerabilities right there in the OS and the userspace software. In terms of the impact on the number of vulnerabilities, eliminating C and C++ would go way further than eliminating black box "security" hardware, just because the huge amount of C and C++ code, much of it written hastily and committed the moment it "runs on my machine", presents a much larger attack surface than the black box hardware + software system. But of course the FSF will never recommend ditching C and C++.
Anyway, ME is likely to be a much higher value target for hackers. A compromise there would compromise millions of PCs, whereas a UEFI hack would be specific to one vendor.
This is missing the point you can and do have control over the C code which runs on your machine; the same cannot be said for ME. The comparison is entirely disingenuous.