Disabling the Intel Management Engine
wiki.gentoo.org
wiki.gentoo.org
I wish there was more widespread outrage over ME and PSP and "trusted computing" so we could collectively tell them to stop selling this garbage. There's so much cynicism out there, though, that I think the public would hardly bat an eye if they knew that all hardware since 2008 or so has secret backdoors. We're just used to this kind of abuse and control.
I haven't bought a new computer since 2007 because I don't want backdoored hardware. If it really is For My Own Safety, as they advertise it to us, then let me control it!
Of course, there is no specificity to the EU here -- this applies to Russia, China and other countries too.
Edit: maybe Intel is already eligible to a € multiple Billions fine from the EU based on this? (Disclaimer: I have no clue about how such fine works).
This does come at a cost of performance, energy efficiency, high price, etc, but DoD / homeland security offices (or their equivalents) are ready to tolerate it.
Same applies to OSes, but mature open-source OSes are several.
You are also talking about defense politics, i.e. the military sector. That and the secret service sector is not covered at all by EU legislation and EU executive.
Also, I don't see why after looking at interests banning Intel from doing so would be advisable. Most relevant EU countries have close cooperation with the US in the military and secret service sectors.
That said, defence ministers usually don't outlaw things. It would be the parliaments. And EU law might actually hinder them from doing so, given that it first and foremost focuses on enforcing open competition and free flow of goods.
The important EU states certainly have the same back door access or a 'trusted' means of disabling it.
Freedom is for the powerful and important, not the pish posh tax slaves these Grace's fatten themselves upon.
Can't find source for this, but a few months ago I read that US (NSA, CIA) and EU (BND) agencies get the same Intel CPU WITHOUT IME, even more NSA made it a requirement for Intel that IME must be completely removed.
http://www.zdnet.com/article/researchers-say-intels-manageme...
I've not tested it, but it looks like you flip a bit and it all goes away. Well, slightly more complicated but that's the gist of it.
With this out of the way, here's the TL;DR: like most corporations executives, the fundamental goal of most officials in place isn't to conduct their mission/mandate but to further their own power; two motivations which ideally go together but in actual fact seldom do. Only the illusion of the former is actually necessary to achieve the latter.
I won't elaborate much because this view amounts to a borderline revolutionary thesis of sorts (calling for a new kind of regime, in place of the disingenuously called "representative democracy"). It's interesting but it's a book, not a comment.
Just recall history and ask questions about:
- The subtle and yet vast spectrum of 'corruption': where does it begins, how far it goes, even after every involved party has died?
- The illusion of safety or 'acceptable' conduct that officials (or execs) can convince themselves of, regarding their organization and themselves: how cognitively biased can human beings be, paradoxically increasingly so as the stakes go higher?
- When we could predict with reasonable confidence that things could go very wrong very fast, did we always manage to prevent just that from happening? Did we even try to the best of our then-capabilities? (Don't even go Godwin on that, not even wars, think market crash or viruses).
- How often in history do we need, as whole societies, the lessons of examples and dire consequences before we put our act together? What is the limbic value of 'could' versus 'hasn't yet'?
Once you realize, as I did some time ago, that we are much less rational beings than anything else, every mind-blowing decision you've witnessed in your own life by people who should have known better becomes not just possible but likely and even understandable, if not outright predictable.
My personal contention is that we'll basically need to go through a 'black swan' of sorts to really deeply learn about electronic safety; much like knowing about germs and viruses did not automatically provoked decent health procedures even by health professionals, let alone the public. But now we do wash hands and sanitize rooms. Just consider how hard a lesson it's been to learn for humanity.
We are in the infancy of the electronic age; I'm afraid it will get worse before it gets better. I just hope it will take the form of a temporally 'short' catastrophy rather than a whole new medieval age of sorts, "dark ages" as seen from a hypothetical future; but the more I observe human beings today, the less confident I feel about us taking the high road directly. Especially when lives are threatened not clinically but rather socially and psychologically. Our survival instincts tend to be numbed when life/reproduction isn't directly threatened.
At this point you may go Orwellian because it's almost less frightening than what's potentially facing some of us on this planet, and our societies appear to be both very resilient yet very susceptible to flaws (probably goes hand in hand). And when there's a flaw... be it legal, psychological, or otherwise... you know someone someday will exploit it. Circumstancial aspects like this ME merely serve as paths to what will eventually become history, but alas it's almost impossible to predict which particular aspect will be the trigger, as impossible as it is to shield ourselves from all angles. But whatever, it too, shall pass.
This isn't to say we can't mitigate because we absolutely can and should (I do try personally), but we can't really alter the shape of things to come because it would amount to changing human nature before the fact. Never happened in history. I don't think evolution works like that, period. Sorry for taking the discussion into a rather philosophical light, but that is my best answer to the 'whys' you asked and seem concerned about —concerns that I share but fail to astonish me nowadays.
Oh, we are incredibly diverse and adaptable. It matters very little that almost all of us are wrong, until it becomes "absolutely all".
I just hope that black swan happens before we start directly plugging our brains into the network. If it does, I am confident we will be fine after a few decades.
I know purism is just neutralizing IME, so it's the same as this, but they're the best solution right now, and I hope that by supporting them, I participate in a clear message to the industry that I don't want their undocumented blackbox on my hardware. Who knows ? Maybe one of the major players will take the hint and try to remove them, or document them. Or maybe a new player will displace them.
[0]: https://puri.sm/posts/reverse-engineering-the-intel-manageme...
[1]: https://puri.sm/posts/neutralizing-intel-management-engine-o...
Also, Purism is taking steps to get coreboot to run on their laptops[1][2], so the graph on this website isn't even right anymore.
And I just found out that, interestingly, the T400 and X200 both come with IME. The only difference is that the AMT can be fully disabled on older intel chipsets[0].
[0]: https://libreboot.org/docs/hardware/gm45_remove_me.html
[1]: https://puri.sm/posts/coreboot-on-the-librem-13-v2-part-1/
[2]: https://puri.sm/posts/coreboot-on-the-skylake-librems-part-2...
Purism has mentioned they may take interest in porting the rest of the way to libreboot someday.
The real issue too is that a lot of naysayers dislike Purism because they provide modern competition to people selling Librebooted laptops.
If I read it right they do the same as described in the gentoo wiki page (get rid of every module except the bring up).
we take the extra precaution of neutralizing the ME itself (removing everything but the “hardware initialization” module)
Am I missing something?
It seems like their current devices are sold with me_cleaner being ran, along with removing several "fuses". Which is pretty good.
I'm still unsure if buying these laptops actually sends a signal that this isn't OK. Intel gets their money in the end.
And even then, your RAM has proprietary code running on it (I'm not aware of any DDR4 that doesn't have embedded SoCs for initialization, none of that is done in CPU firmware anymore), your hard drives can have up to entire embedded SoCs with proprietary code running on them, and there isn't an unencumbered 802.11AN wireless chip in existence. The only bright side to that is none of that hardware has system-wide access the way these backdoor coprocessors do.
Most people don't know that IME exists, they won't know either. You won't see an uproar from the consumers, because there are few that care (us). You are better off informing the general public in my opinion.
EDIT: I'd actually put money into RISC-V products instead.
We sell an x86 server where the management engine is unreachable; there is no path from the external network to the ME. I can tell you point blank that most enterprise customers are unaware of even hypothetical issues there or for that matter with IPMI implementations. We stopped using this as an early feature in our customer conversations because they just couldn't care less about it until they hand you off to their deeper technical team (if they even have one, which is not as often as you'd think if you have not realized that security in enterprise datacenters is almost always an afterthought). Otherwise it just doesn't come up very often.
Until high-volume customers take a concern, no amount of outrage or paranoia is going to make any difference. You might as well be outraged that, for example, implementations of some BIOSes are so poor that the measured boot (hashes to TPM) don't cover all of the configuration items or vendors fail to correctly lock down their firmware flash or update path. This is pretty common and you don't hear about it because most people can't make measured boot work and generally don't even try.
Security, in general, appears to be mostly viewed as optional. Obviously I think getting this right is important, in our case for other reasons, but in and of itself people generally view security as an expensive vitamin.
And yes, security will be seen as optional. Because security is not the product, and thus not the revenue source, of most of these companies.
I'm not pushing our solution, just sharing what I have observed. Management engine in practice will _always_ be unpatched. It is _inherently_ unsafe. Anyone who thinks they will keep their patches up to date, unless they work at Amazon or some other entity where they can institutionalize it, is crazy. I had a CIO directly tell me their mean-time-to-patch CVEs in their exposed servers was two years. The statistics on Linux bug lifetimes show that 5Y is not uncommon.
Security is our underpinning but not how we sell (for the reasons I am explaining); there is a very good reason for that which is that people don't actually buy real security, they buy tools to pass audits. You can see shadows of this in the way that companies continue to deploy vulnerable agents even when they are revealed to degrade host security, or in the resistance to internal secure communications (and the reaction in general to TLS1.3).
Security practices inside large enterprises are bizarre and the result of perverse incentives. Let me give an example. The internal use of Websense proxies, for example, will tend to block encrypted content within TLS connections using entropy detection; a malicious actor will simply use an entropy reduction strategy (bananaphone or whatever trivial solution); a legitimate user who is sending an encrypted document will have that document blocked. People justify these tools as meeting the need to allow inspection of traffic; however your Websense administrator is not actually qualified to see all of the traffic that flows over the proxy (for example, does being able to read the CEO's mail make the admin an insider?) and protocols that carry content that is both safe-to-inspect and unsafe-to-inspect (the CFO's password, for example) do not differentiate the two making inspection inherently dangerous. A decade and a half ago, I knew someone who peeked at the loading dock, invoicing and shipping so that they could predict how the quarter was going to time stock sales.
That's a comical example but it's one we have directly encountered in the secure exchange of cryptographic material; but similar issues crop up all over, from the use of transparent proxies and corporate CAs (to "allow inspection") to all manner of craziness.
The facts lead you to a world view that is even more cynical than the idea of security as theater: instead, security as _ritual_. "I need this server to be secure, I'll install some agent"; "We need this server to be inspectable; I'll disable all forward-secrecy protocols and decrypt and inspect the content." And so on.
So .. I don't think it's high volume or anything else like that which is an outcome of process rather than a choice. It's that many companies long ago adopted a world view where any kind of real security is as far from consideration as possible.
(not speaking for skyport, speaking for me)
I honestly believe that a lot of people would be capable of taking responsibility for all of this themselves. I think they just don't want to. They have neither the time nor the energy to put constant pressure on all of these organizations. They have so much other stuff to worry about in their lives.
e.g. if I read a story on HN about some police brutality, posted by some familar, karma-rich HN user, I'd quite possibly give it more credence than a report from said police department denying it. Just because I'm in the HN tribe.
This effect is why posting deliberately inflammatory fake news on platforms like Facebook is so damn effective. The typical pattern is (a) establishing the author's tribe (e.g. gun-toting 50-something male living in a southern state) and then (b) launching the attack.
I really like to think that, as a rational person, my bullshit detectors would fire... but its an interesting thought experiment as to what I'd give credence to just because it was uttered by a respected HN poster.
Cheap RockChip-based Chromebooks. Not even CPU microcode needed. No binary blobs anywhere, as long as you disable 3D acceleration:
Apple's SoC's, including the CPU, are designed by Apple, not ARM (the company). They run the ARM instruction set but the CPU core is not ARM's design. The last Apple chip to have ARM-designed CPUs was the Apple A5(X) with the ARM Cortex-A9 from 2011, every Apple chip after that has had a CPU designed by Apple. Additionally, the SoC most likely contains "hidden" core(s) not unlike Intel ME (like most SoC's do) that boot up the system and perform power management and other peripheral duties.
ARM is not the answer because they don't do their own chips. They license the technology and their clients are free to add whatever management engine hardware to their SoC.
An ARM-based SoC could be built without hidden hardware or firmware blobs but I am not aware of a SoC that could run on completely free and open software.
The approach of Intel and AMD is completely hostile to anybody who cares about such things.
Even Tesco was selling them a few weeks ago!
Update: I know other vendors (AMD) do that too, but it still looks monopolistic. First of all, Intel has a huge CPU market share. Also, probably the vendors together constitute a monopoly.
It also shows that the market of people willing to put money where their mouth is on this are fairly few and far between. The Raptor workstation crowdfunding campaign promised to get rid of all the proprietary firmware in the system and failed by a large margin.
I would gladly buy one
EDIT: Hah, jknz beat me to it.
It's almost 20 years ago since the public convinced Intel to remove a feature from their processors which would seem almost harmless today: https://news.ycombinator.com/item?id=10106870
However, the serial number was not heavily marketed as a security feature, unlike ME and all the other new and oppressive functionality today. The security argument is impressively powerful --- and more scarily, it seems the companies and government have almost perfected how to harness it.
I do not believe the argument that these changes are undertaken out of concern to protect users, whether it is made with respect to "features" of Intel chips (including Intel SGX), corporate-controlled OS, advertising-supported browsers, etc.
It is difficult to prove such organizations are deliberately trying to make things more difficult for users to control, unless of course employees inside these organizations speak out. The organizations can always provide alternate reasons for doing what they are doing.
However I recall reading of a comment made by Gates in the 1990's, at a time when he wanted Windows installed on every PC sold, that he did not like the idea of users potentially changing BIOS settings. I can only guess as to why, but it is curious to me that we are left with certain strange historical artifacts such as Windows always needing to be installed in the first partition. Other OS do not have this requirement.
While that sort of deliberate subterfuge may be difficult to prove, I think it would be easier to argue these organizations believe (or pretend to believe) that users are "incapable" in ways that have no basis in fact.
You, dear user, are incapable of controlling your computer. We, benevolent organization, can help. Just sit back and we will take care of everything.
1. Download and unzip the Gigabrix-BSi5ha-6200 IME update archive (http://download.gigabyte.us/FileList/BIOS/brix_bios_bsi5-h-a...). Use F5_BIOS/image.bin from that archive.
2. Start "python unME11.py image.bin"
3. The uncompressed modules are located in image/00004000.FTPR/* after that
4. You can i.e. load image/00004000.FTPR/kernel.mod in IDA using 80486 in 32bit real-mode or use "objdump -m i386 -b binary -D kernel.mod --adjust-vma=0x80000" with entry point being 0x80000 or "objdump -m i386 -b binary -D bup.mod --adjust-vma=0x2d000" with entry point being 0x2D04C
before: http://download.gigabyte.us/FileList/BIOS/brix_bios_bsi5ha(a...
after: http://download.gigabyte.us/FileList/BIOS/brix_bios_bsi5ha(a...
You can see that there is an extra function call added that tests for response.length.
Given the easy availability of the assembler dump you can expect progress towards demystifying IME. I'm not a professional in the security field, but I sense that there is lots of possibilities by just doing a "strings image/00275000.NFTP/amt.mod". Gigabyte might be special, but they have left their assert prints in the code and you can get a sense what the thing is doing...
Also, a normal user of a computer cannot do whatever they like with Intel ME, so its the least useful circumvention measure I've ever heard of. GDB is infinitely better.
Not to mention that most DRM depends on the encryption being done outside of the computer's CPU. HDMI's DRM relies on the local computer not being aware of the contents of the stream and the monitor itself does the decryption with burned-in keys.
What would be the justification for Intel going through all that trouble to do that (besides a conspiratorial "the NSA needs it to spy on everyone")?
The impression I've gotten, to this point, is that Intel just doesn't care enough about people in the general public who are bothered by the IME to publicly support ways to disable it. Governments had enough buying-power to get Intel to implement an unsupported workaround, but I'm not convinced Intel has a motivation to make accessing that workaround hard.
Besides the real reason? I dunno.
Why would Intel go through all the trouble of creating ME or the broke AMD PSP at around the same time? This is hardwired in silicon, is not cheap to do and definitely needs huge business justification to initiate, implement and maintain. What's the business case?
Are they charging a premium for these features and disabling it for everyone else as they would if it was actually a 'premium' feature? Are they giving an option to those who don't want it to disable it without ado?
No, they are pushing it on everyone. That itself compromises ME. How do we know there is no NSL in effect forcing both Intel and AMD to implement this. Nobody does. But it is an intrusive piece of tech that has complete authority over your PC.
Yes, the NSA exists. Yes, it's their job to spy on people. And yes, it's perfectly valid to include mass surveillance in your threat model. But these constant, uncorroborated claims that the NSA boogeyman is hiding behind every rock and tree are starting to become quite tiresome.
Yeah indeed, they have backdoor-ed every ISP, nation, router, HDD, what-have-you in existence and these people keep telling boogeyman tales.
Tsk tsk tsk. How tiresome.
This is exactly the kind of hyperbolic nonsense I'm talking about. You can't claim that every HDD in existence has an NSA-installed backdoor installed in it without providing any evidence.
If the NSA's capabilities were nearly as extensive as you're claiming, the US wouldn't need to bother maintaining a military. They could just remotely command all of North Korea's computers to shut themselves off, then sit back and wait around for their surrender.
I'm not saying mass surveillance isn't a problem, or even that the NSA doesn't have a backdoor installed in IME (I certainly don't have evidence to the contrary); just that people need to stop exaggerating the threat, or making claims about the NSA having compromised any specific system without providing any evidence to back those claims up.
Remember when the US shut down NK's internet ? https://gizmodo.com/so-who-shut-down-north-koreas-internet-1...
Remember when the NSA was revealed to have a malware that could infect hard drives, being potentially undetectable ? https://motherboard.vice.com/en_us/article/ypwkwk/the-nsas-u...
Remember PRISM ? How about stuxnet, and the other couple of viruses that are almost surely the NSA's.
Sure, those are not backdoors installed by the OEM, rather they are malware that the NSA can use to infect (lots of) systems. But let's not kid ourselves, the NSA does have a ridiculous amount of power, and we have lots of evidence of it.
At this point I'd be rather surprised if the NSA haven't hacked my fridge yet somehow.
_Could_ the NSA have the ability to utilize IME somehow as a means to infect computers? Certainly. Do they _actually_ have that capability? We have no idea. Same goes for your motherboard's firmware, your hard drive's hardware, and any number of other possible vectors. They _could_ be compromised somehow, yes, but let's not claim that any specific motherboard firmware, HDD model, or CPU processor brand definitely _is_ compromised without evidence.
There is an equivalent article from Ars technica, if "theregister" isn't to your liking.
As for the evidence on routers and Internet infrastructure, you should pay more attention to leaks of state-sponsored tools, like the equation group leaks and the CIA one.
Do you want to live in a free society or not? Because this is not acceptable to a free society.
The fact of secrecy around this issue is the only thing to be doubted. Its no secret to non-Americans/concerned citizens; if you choose to continue to be ignorant, I choose to set you the challenge: go and find out for yourself just how bad it really is with the NSA. (It is atrocious.)
If I were an American and believed in what the NSA was doing, I'd want to know what they were doing with their budget if they didn't at least try to get a hardware back door into Intel CPUs. Why waste budget on finding exploits in patchable software when they can go straight to the silicon?
The Intel IME is far different than 'rock and tree' to an organization of 40k employees and $10B budget tasked with bypassing stuff like the IME.
Well, some companies and users use the IME to enable theft-prevention technology. If you can circumvent the IME, you can easily steal a laptop and disable this theft-prevention technology.
If that’s worth building an ever more closed walled garden is another question.
Isn't the ability to spy on everyone the official mandate of the NSA?
If you were worried about NSA spyware that tunnels through your OS... well, then you may as well just be worried about NSA spyware in your NIC.
Because in the end, even if the ME was directly connected to the NIC, it still needs to know how to talk to the NIC (thus why NICs have drivers...). When you use an Intel NIC, the ME knows how to talk to it, and everything is hunky dorey. In practice, Intel could probably build a database of common non-Intel NICs and load all of their drivers into the ME. But really, if we assume that the ME exists for business reasons, then its obvious why Intel will just keep it all as Intel. They are nominally selling something that is advantageous to large organizations, and would like said large organizations to buy as much Intel gear as possible. Said large organizations believe that ME provides sufficient value to go with Intel NICs instead of other NICs.
If it's for what Intel claims, then they would trivially offer an option for the customer to disable it. Hell, they could even make it a selling point for higher-margin chips like Xeon.
Does ME have business purposes? Sure. But their staunch refusal to allow disabling by nongovernmental customers does not pass the sniff test. There is clearly some other, non-business reason for it.
> then you may as well just be worried about NSA spyware in your NIC
If you own my NIC but not my CPU, I can encrypt my traffic and blind you.
If you own my CPU (especially my AES-NI ISA), my options are more limited. Much higher-value target.
>especially my AES-NI ISA
why aes cpus specifically? you're free to not use aes instructions. besides, if you own the cpu, you load whatever shellcode you want, no need to backdoor the aes instruction.
good luck getting a system compiled that does not use them at all. Might be possible with gentoo and the right configuration as it compiles everything, but with a dominantly binary distro like Ubuntu or Debian you're SOL.
I was just saying my options are more limited, and the options for someone unwilling to recompile their own software is very severely limited.
But even if I'm running, say, software-only Salsa20 with all compiler optimizations off, if my CPU is still owned, my keys are still at risk of silent compromise.
The only real defense is to ascertain the processing limitations of IME and then choose your crypto primitives/implementation for both processing and memory hardness that exceeds the ability of the IME's lower transistor count and/or clock speed to keep up with.
It's fairly light on details, but my interpretation is that for a NIC to support PXE boot it has to have firmware that exposes a standardized API so that the boot loader can functions as a DHCP client and a TFTP client. As far as I can tell, the NIC doesn't have to provide some standardized method for general access, just those two things. The NIC could even have a completely different, completely separate API that it expects the OS to use, and just has some firmware that acts as a shim to expose to the boot loader the PXE client API.
Assuming this is true, Intel ME could access the NIC using the PXE boot API, but this only gives it the ability to act as a DHCP client and TFTP client, not arbitrary networking operations.
I could be completely wrong about that, though. This is, at best, an educated guess.
Dear Intel, please PLEASE only use a solid state dongle with no moving parts! :-)
If ARM continues to supplant x86, and an open ISA like RISCV starts to nip at ARM's heels...
You're going to be hard pressed to find a moderately complex SoC without something like that. At a bare minimum, reset and power state sequencing is complex enough to offload to a microcontroller style core these days. The iMX6 is the biggest, most reent SoC I an think of without that.
Then there was an effort to create a secure interoperable platform for smartcards, it was Global Platform and it uses Java card for implementing their goals. All post 2000 smartcards are compatible with GP:
https://youtu.be/WMII5G98AdM?t=608 (skipped to the part where he mentions that it's Java)
[1]: https://firmwaresecurity.com/2017/05/07/intel-me-based-on-mi...
Some background, for anyone not familiar:
https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_deb...
That being said, it is also reasonable to expect a lot of modems, RAM, and hard drives could use MINIX for their control processors.
(Edit, in response to all of the comments in reply to this) Wow, I had no idea so many tiny devices ran java..
[1] https://www.reddit.com/r/yubikey/comments/6ji8ag/updating_yu...
We see you Intel... with your stinky spies peeping out from the depths of our computers....
https://www.bleepingcomputer.com/news/hardware/researchers-f...
There's no way that both Intel and AMT simultaneously decided to backdoor their hardware out of consumer demand. The order must have come from above.
(Okay, sorry, that's as much of a conspiracy theorist as I get to be.)
"According to a highly technical blog post, Positive Technologies experts revealed they discovered a hidden bit inside the firmware code, which when flipped (set to "1") it will disable ME after ME has done its job and booted up the main processor.
The bit is labelled "reserve_hap" and a nearby comment describes it as "High Assurance Platform (HAP) enable."
High Assurance Platform (HAP) is an NSA program that describes a series of rules for running secure computing platforms.
Researchers believe Intel has added the ME disabling bit at the behest of the NSA, who needed a method of disabling ME as a security measure for computers running in highly sensitive environments."
TL;DR the evidence is that the NSA made Intel give them a way to DISABLE the management engine on their machines, not a backdoor.
Here's some examples of solid evidence
- Leaked documents either from Intel or the NSA documenting the NSA pressing Intel to provide backdoors, and Intel accepting
- One of the APT groups believed to be associated with the US government is found using an ME vulnerability in the wild, before the vulnerability became publicly known
- Refusal or extreme reluctance on the part of Intel to fix a discovered vulnerability
- A vulnerability which is clearly intentional, like having ME automatically execute any shell script sent over the network signed with a particular certificate or something.
Examples of circumstantial, but still quite compelling evidence:
- A vulnerability which appears intentional, as in it doesn't require any buffer overflow or shell code injection or abuse of certain registers, but rather seems to be a part of normal operations.
- Intel pushes a change to fix an ME vulnerability, but that change simultaneously introduces another vulnerability.
- Evidence that Intel, while giving the US government the ability to disable ME, refuses to give such an ability to other large customers (Google, Amazon, other governments, etc.), for any amount of money.
Seriously, if someone comes forward with evidence like the above, I'm completely open to accepting the possibility Intel ME is an active backdoor for the US government.
I'm not intimately familiar with the situation but I heard some chatter a few years ago about Google (which likes to use Coreboot on its Chromebooks) asking Intel for documentation and source code for various firmware components including the IME and being turned down.
Researchers recently found an undocumented bit can be set in recent IME versions with a name ("High Assurance Program (HAP)") said to be associated with the US government which disables most functions of the IME.[1]
[1] http://blog.ptsecurity.com/2017/08/disabling-intel-me.html
If you have a source to back up the claim that Google offered money for access/documentation for disabling ME and were rejected, that's something, though.
I did some quick searching (I mostly skipped the coreboot mailing list which is probably the most interesting place to look but I didn't want to spend too much time) and every reference I've found alludes to someone from Google or Coreboot _asking_ for Intel's assistance in the form of documentation or source code, which Intel has plenty of non-NSA-related reasons to refuse to provide for free (licensed code, preserving competitive advantage, DRM shit, etc.). I couldn't find any references to anyone offering to _pay_ Intel for ME firmware source code or similar but then again such an offer would hardly be public. So this is weak circumstantial evidence at best.
I find AMD's refusal to cooperate with the FOSS community on the matter of its management coprocessor to be slightly suspicious as well as it's an area where it could possibly gain a significant competitive advantage vs Intel but a lot of Intel's reasons for keeping the IME locked down apply to AMD's insistence on black boxing its PSP as well.
The NSA gets to dictate to Intel what it wants in the chips because the US government is an absolutely huge customer. Hell, Intel has an entire subsidiary devoted to selling chips to the federal government (https://washingtontechnology.com/articles/2011/08/30/intel-f...). And if the NSA says computers must meet these standards to be able to interact with classified data, well then Intel better make it possible for their chips to meet those standards or they stand to lose a lot of money. That's why they get a special kill switch for ME.
Which isn't to say that the NSA could use that influence to inject a backdoor. They can't refuse to certify a computer for handling classified information because the manufacturer didn't do something to their other computers.
You can control that bit, as shown here: http://blog.ptsecurity.com/2017/08/disabling-intel-me.html . Of course, that method isn't documented or officially supported by Intel, and you could brick your machine if you mess up, so that's not exactly what you meant. I think Intel definitely should document it and provide official support. As to why they don't currently, I have some guesses. The first is general lack of interest: it costs money for them to support this new feature for everyone and make sure it plays nicely with everyone's setup, and maybe there isn't enough customer demand for the feature. The second is money: I wouldn't be surprised if they sell their chips to the government with the bit already set in firmware at a markup. Making that easily available to everyone means less money.
So, at the very least, a class action suit to cover the cost of running it...
How to hack a turned-off computer, or running unsigned code in Intel ME | https://news.ycombinator.com/item?id=15298833 (Sep 2017, 239 comments)
We instead need a platform (CPU+peripherals) which is open by design; no more ME or closed device drivers, blobs etc. No matter if it's 10 times slower than the equivalent by Intel or AMD or draws 10 times more current than the corresponding ARM processor; the point is funding such a development, producing it and selling it even to a small fraction of users will send a heck of a message. Also a well crafted PR campaign could do the rest (does your boss know that all his/her files and communications can be accessed by Intel, AMD and every government with ties to them? What about making him/her aware?). If someone starts a project like that, I'm pretty sure I won't be the only one ready to donate a few quid right now.
AMD has something called the PSP which essentially serves the same purposes of the IME which is also undocumented and cannot be disabled.
[1] https://securelist.com/absolute-computrace-revisited/58278/
Intel's advantage is built and defended on economies of scale. Making a hundred million of one thing [1] is more profitable than making 50 million of two things. Particularly if enterprises' demand for IME is stronger than consumers' demand for non-IME chips (assuming no strong externalities, e.g. NSA corruption).
I think the Intel Management Engine is crap. But there's a comprehensible reason it's there.
[1] https://www.ft.com/content/beff6e56-53ed-11e4-80db-00144feab...
[1] I'm aware that a "High Assurance Program" bit exists that disables most functions of the IME but you can't expect the average consumer (or even the majority of technically-inclined consumers) to own an SPI flash programmer and to be willing and able to use one on their motherboard. Furthermore, researchers believe that setting this bit would cause any computer with the Verified Boot fuses set (i.e. pretty much any recent laptop) to fail to boot[2].
[2] https://github.com/corna/me_cleaner/issues/53#issuecomment-3...
Beyond the obvious economy of scale argument, why don’t consumers want that? I thought things like Apple’s remote lock/wipe feature were selling points for anyonel concerned with theft.
(As an aside, it doesn’t feel accurate to term this a backdoor without evidence that it’s being used without the owner’s consent)
We would all be fine with IME if we had access to it, could define the keys, and enable/disable features of it. Locking users out of their own hardware is not acceptable. I'm the only one that should be able to remote lock/wipe my phone. It should not be possible for Apple. They shouldn't have the keys. It's my phone. Even if I did trust Apple, I don't trust the government.
The other thing to remember for effective advocacy is thinking about what normal people experience. If you say Apple shouldn’t have the keys, you’re also saying the average person has to be good at key management; most people are happy to outsource that. Conflating the issues of mass surveillance with control over your own hardware is great if your goal is confusion but I don’t see it producing results.
It is not even relevant whether the door was left unlocked intentionally. An unlocked door is a security problem, whether it was put in place intentionally or due to negligence.
Putting a complex piece of software that you cannot disable, that is potentially reachable from the network, and that won't be updated into every machine is the software-equivalent of building a safe with a cardboard wall: Even if it's not intended as a backdoor, it still has to be treated as a de-facto backdoor for security planning purposes, and whoever uses cardboard to construct a safe wall is to blame.
Also, you do not judge security based on what has already happened nor on what you can prove to be insecure. The default assumption is that things are insecure, unless you can demonstrate that there are good reasons to believe that it's not--just as everywhere else in reliability engineering. A bridge is not assumed to be safe to use until it collapses or is demonstrated to be unsafe--a bridge is assumed to be unsafe to use until it is demonstrated that to the best of our current understanding of how to build reliable bridges, there is no reason to expect failure. A bridge where the builder makes a secret out of how the bridge was built is never considered safe.
Please read the piece linked above on Computrace. I am not very familiar with the inner workings of Find My Mac and other AppleID-associated features but I'm going to go out on a limb and say that those features 1. don't involve injecting code into system processes in the exact same manner as a BIOS-level rootkit and 2. aren't preactivated without the owner's knowledge or consent so the attack surface they create is likely much smaller than that of something like Computrace.
Also, if you like, please elaborate on why the economy of scale argument is "obvious".
[1] https://arstechnica.com/information-technology/2017/05/intel...
Edit: Management coprocessors are also rightly called backdoors because they operate below ring 0 meaning that if we cannot trust them (and we can't because they are largely black boxes to us) then we cannot trust our systems as a whole.
Management: Imagine you manage and support 10,000 desktops and laptops. Remote access is essential (otherwise you'd effectively pay something like 2/3 of your support staff to cover time spent walking around), but typical remote access depends on an available processor, memory, OS, etc. For the many cases where those components aren't all available (something failed, OS is being updated, need to disable a component to diagnose it, etc.), you need out-of-band remote access, such as what Intel ME provides. It's a high-value service for corporate IT.
Security: You need an out-of-band machine to perform crypto functions, to protect the crypto functions against in-band attacks (e.g., in the OS, BIOS, applications ...). The out-of-band machine can then be used to verify the integrity of BIOS, OS, and other important things. It's also useful for DRM. If you're in corporate IT, you suddenly have a way to provide reasonable security guarantees across your 10,000 computers, a huge step forward.
If you are in corporate IT, or if you're a vendor wanting to enforce, protect, or hide your media or other proprietary bits, end-user control is undesirable. Obviously, that could be optional for owners of the computers who have other needs, but somehow it never works out that way ...
EDIT If you really want to learn about it, save your time and go to the source:
Platform Embedded Security Technology Revealed: Safeguarding the Future of Computing with Intel Embedded Security and Management Engine by Xiaoyu Ruan, a security researcher with the Platform Engineering Group at Intel
Neither AMD nor modern ARM chips are much better in this regard, both have some form of management system (AMD has a "Secure Processor" based on ARM's TrustZone, and ARM has TrustZone).
If $comercial_seller buys $chip_vendor expensive management solution does then have "legal backdoor" access to any device it sells?
What's the "chain of command" for accessing the IMEs of this world?
https://software.intel.com/en-us/articles/remote-configurati...
I am seriously thinking going Stallman because of this and not connecting to the internet at all, at least not from all the machines.
(I've run systems, at least for a time, relying on both.)
Otherwise, airgapping and read-only media might be an option, for transfers you need / want to perform.
Current draft involves two monitors, two cameras, and protocol crazy enough to confuse any firmware.
[1] http://blog.ptsecurity.com/2017/08/disabling-intel-me.html
Don't have any enemies? Well then, you've got nothing to fear. But lets say you do something big, which will change society, perhaps disrupt an existing American Military-Industrial player .. well then, that small component is going to keep you down, brother.
You will get the benefits of the management engine without any external exposure.
Back when I was a kid, after hiking to school in 4 feet of snow uphill with no shoes, if I were building a PC or adding a new card, I would spend a bunch of time flipping little DIP switches to set things like addresses and assign IRQs. I'd reboot and my Gravis Gamepad controller would work, but the SoundBlaster wouldn't. So I'd power down, flip some switches and try again until I could get everything working.
Those switches went away, but the underlying issues remained. The new method was some firmware that did a bunch of pre-boot configuration. That was refined over the years and now today there's an entire computer running it's own OS that manages all this stuff. It works amazingly well.
However, once the machine is up and running, most people (especially consumers) have no need for it after that. It would be nice if it just powered down and waited for the next reboot. However, a little hidden computer was too useful to be ignored and it's used for a bunch of things including DRM (it can have secure-enclave-like functionality) and remote management. I'm not sure we have an exhaustive list of what it can do.
I'm really impressed about how people manage to self-convince themselves so much about something they don't know about to the point they can explain their imaginary tech stack with such aplomb.
The ME is not needed to do PnP conf (or whatever it has been renamed too those days), and to the best of my knowledge is not used to do that and has never been.
ACPI/EFI & their friend are sufficiently hosted on the CPU, and can run platform code at so called negative privilege level at runtime. I expect those computers with ME disabled to run as well as if ME would not have been disabled, including if you add or remove an extension card.
However you are right about remote management (that's the main advertised application of ME) and probably DRM stuff.
https://news.ycombinator.com/item?id=15445826
If you really want to learn about it, save your time and go to the source:
Platform Embedded Security Technology Revealed: Safeguarding the Future of Computing with Intel Embedded Security and Management Engine by Xiaoyu Ruan, a security researcher with the Platform Engineering Group at Intel
Make sure someone else has managed it with your same board to know it works.
[1]: https://wiki.installgentoo.com/index.php/ChromeOS [2]: https://9to5mac.com/2017/03/02/apple-ios-market-share-k-12-e...
You also get to see some damn fine hackery in the OP, in the finest spirit of Gentoo. Although it is pretty advanced for those of us who habitually end up repairing broken toolchains without breaking a sweat 8)