Does ME Manufacturing mode allow the user to change all the configuration? Does it mean that hackers who incidentally purchased such a machine (but probably not Apple's) with ME Manufacturing mode enabled, can theoretically port coreboot to the machine, then flash their own public key fingerprints into ME, using Boot Guard to protect firmware signed by themselves instead of OEM's?
I remember several bunches of Lenovo laptop series released a few years ago seems to have the same vulnerability, and porting coreboot to those computers with earlier chipsets is a real possibility, only prevented by Boot Guard signature. But finding these unpatched and vulnerable series of machines is a hit-or-miss game with minimum chance of success. If someone really implements tools to do all these things, is it possible that the secondhand vulnerable motherboards would be the gold in the hacker communities and be sold at a high price?
Another fact is that ME is a part of the PCH, which is located on the CPU package. If a hacker has access to a BGA rework technician in a professional repair workshop, it should be possible to desolder the original CPU from the board, and install a new one with unconfigurated ME to "own" the machine.
Exactly. Remember Intel ME is a great utility and has some awesome abilities. The issue that people have is not the fact there is a CPU running another CPU that looks after the main one. It's that it's closed source and has remote control capabilities that can not be controlled by the user.
If Intel would just allow an owner to build and flash their own Intel ME version using their own private/public keys then no one would have an issue with that. It's the fact it's a secret closed system that has full control to monitor everything you do, and can not be fully disabled.
> It's the fact it's a secret closed system that has full control to monitor everything you do, and can not be fully disabled.
To add to that, it also makes code audits impossible.
Intel, AMD, ARM, et al: There is zero, and I mean ZERO reason to hide management functionality from users in this day and age. It's 2018, security through obscurity has been proven wrong time and time again. It's foolish to think otherwise. Edit: grammar.
It's not a coding error. It's built to do exactly what it looks like it's supposed to do: diminish any ordinary person's claim of total control over the behavior of the system, such that, should the need arise, a trained hand can lift the proper latch and intervene, to gain the upper hand, ostensibly so "the good guys" win.
The good guys being those that ordered Intel into compliance with such requirements.
>The good guys being those that ordered Intel into compliance with such requirements.
There is vast case law surrounding our first amendment right to refuse this kind of coercion. No one can force you to present something as yours against your will (at least, if they want it to hold up in court).
What is more likely is that Intel won a great many more government contracts by doing this. They'd make tons of money doing it, so they did it. And if they didn't do it, their competitor would. That's how the system works in this country.
They also won government contracts by not doing it; the High Assurance Platform mode (‘setting the HAP bit’) was a feature implemented by Intel for the NSA, incidentally discovered by security researchers.
Dell sold laptops with this as an option until they were asked not to.
It would be pretty easy for a sizable country or even a wealthy US state to demand that these ‘secure’ co-processors can be disabled at the user’s discretion, via regulation.
From the NSA’s perspective, having the keys to the backdoor is an asset, but having a backdoor at all is a huge liability, now they’re not the only game in town. US businesses and citizens simply have more to lose.
Honestly, I think it’s laziness and inertia more than conspiracy.
> From the NSA’s perspective, having the keys to the backdoor is an asset, but having a backdoor at all is a huge liability, now they’re not the only game in town. US businesses and citizens simply have more to lose. Honestly, I think it’s laziness and inertia more than conspiracy.
You're assuming (fully) rational actors. It's fairly easy to have blindspots when they are (at least temporarily) useful.
nobody is seeing this for what this really is: Apple users compromised by internal agent.
Nation states already paid google employees to target gmail etc. now they targeted an apple employee to make this mistake which allows any targeted attack into those companies that gives mbp to developers very easy to carry out remotely, as this probably leave the remote capabilities put in place for the NSA wide open.
Is the Intel ME that great? I mean I never heard anyone say that they actually use it. The explanation of its capabilities make it seem like a great tool for fleet management, yet nobody seems to be using it.
With other alternatives available, combined with low usage, I’m not sure that neither Intels ME nor AMDs PSP needs to be embedded in every CPU.
I think the specific part you're referring to is Intel AMT (Active Management Technology) which allows the user to remote control into their computer. AMT is a module that runs within the Intel ME operating system.
Intel ME does a lot of things, like the below (we think, no one really knows for sure):
- Active Management Technology (AMT)
- Alert Standard Format (ASF)
- Intel Boot Guard (IBG)
- Secure Boot
- Integrated Clock Controller (ICC)
- Quiet System Technology (QST) / Advanced Fan Speed Control (AFSC)
- Protected Audio Video Path (used in PlayReady DRM)
- Intel Security Assist (ISA)
- Serial over LAN (SOL)
- Firmware-based Trusted Platform Module (TPM)
> If Intel would just allow an owner to build and flash their own Intel ME version using their own private/public keys then no one would have an issue with that.
Note that unless you manufacture the CPU yourself you still cannot be sure if there are no hidden backdoors. For example the ME could pretend it's really running your firmware but at the same time running some hidden code only delegating some operations to your code.
I understand and agree with you to a certain extent, but we're not just talking about a couple of assembly commands that could be misused. The Intel ME is a FULL Operating System running MINIX Linux (edit: MINIX is not Linux, as corrected by @dragonwriter). It has it's own network and apps, that run inside a running kernel, of which you have no access to.
Even if the intentions are 100% legit, this is an operating system that you can not update (as frequently as your main operating system), and has many attack vectors.
Yes, it could pretend to run your firmware, but secretly load it's own, but it's actually quite hard to hide a 5mb (2mb min) piece of firmware in the chip. Research microchip decapping. You can clearly see the different regions of the chip.
But yes, it could be possible to hide a few x64 instructions, or circuits that could be manipulated. But running a remote control environment that can share your screen without your knowledge can only really be done clearly by running a large separate application stack alongside your main chip. (For now, who knows where we'll be in 5 to 10 years).
Hi @turblety, finally I see someone concerned about MINIX and everything that Intel ME can do to invade us, I read most of your comments, and you are pretty aware of the matter, is there a pc/chipset different from Intel and AMD that is free of this backdored tools?? I read on 1 comment from you something about IBM's OpenPOWER? thanks
Wikipedia says that MINIX is POSIX-certified, so it's pretty close (Unix-like). It doesn't seem anyone has shelled out the money for SUS certification, so it can't officially use the UNIX trademark.
The TLDR is that once they started putting a CPU vendor-controlled management CPU on their chipsets, they realised they could use it to implement DRM that Hollywood had been asking them for. We know that AMD has a contractual obligation to DRM vendors not to open source their GPU firmware for this reason, and it's likely Intel and AMD have similar contractual obligations as regards their Intel ME/AMD PSP firmware, as these are also involved in DRM.
Do you have any source for a time this DRM worked? What I mean is that I have watched/downloaded/streamed a lot of pirated content from various sources, using Intel and AMD hardware. CPU's and GPUs. Not once have the drivers blocked the viewing of pirated content via some kind of built in DRM. So if there is DRM baked into the drivers/ME, then what's the point if it doesn't do anything?
DRM doesn't stop you from playing pirated content, the goal is to make the content only decryptable using approved hardware/software, to limit people's ability to copy and paste content Willy nilly and share with their friends in Napster fashion. The determined people still stealing content never will be stopped, but it's inconvenient enough that average people aren't going to duplicate DRM-laden stuff themselves.
Importantly, I think, when there's a higher barrier to content theft, the remaining sources of pirated content are fewer and easier to track.
> Importantly, I think, when there's a higher barrier to content theft, the remaining sources of pirated content are fewer and easier to track.
Except DRM on end-user devices is done with security by obscurity and it's never ever worked for media. And never will.
So there is so many sources of pirated content that attempts to track of stop them never succeeded. Fortunately NSA and other government spying organizations can still have their backdoor because "Hollywood needs DRM" bullshit.
You can only flash coreboot if the BootGuard isn't blown. Nothing else will allow you to run coreboot on a mobile Intel platform because the CPU has a hard-fused hash of the public key for the IBB (boot code in the CPU ROM/factory microcode) and via that, the ACM. (Authenticated Code Module, loaded via ME)
This means that you cannot run an Intel CPU without getting an ACM signed by Intel. And that ACM only works with the ME and an Intel formatted SPI flash partitioning scheme.
Keep in mind that this hard lockdown only applies to those SoC-ish chips like the mobile PCH+CPU combo chips. Once the PCH and CPU are separate, it's a different story with real options, all the way down to replacing the PCH with one that doesn't have the fuses for BootGuard blown.
Manufacturing mode does allow you to access all of the SPI, but it doesn't allow you to add malware of change the firmware as long as BootGuard is still on since you need the RSA private key from the manufacturer to change the firmware, or the RSA private key from Intel to change the IBB+ACM combo package.
The Lenovo series you are referring to had a similar but different issue; BootGuard was in validate-only mode, so you can edit the SPI flash and remove the UEFI part, but leave in everything else (ME, GbE, config, IFF, partition data etc.) This has been a non-default configuration for a while, and as you noted, even then it was hard to find one that had that specific firmware/fuse combination.
The ME on platforms with sockets is in the PCH which is on the mainboard, not on the CPU, so in theory it is possible to man-in-the-middle the CPU-PCH communication.
Another note: a lot of Intel boards have the CCA debug options for ME still enabled due to a mishap from Intel; CCA is the Closed Chassis Adapter which basically runs JTAG over USB3 directly onto the ME CPU core. Getting a USB 3 cable and removing some pins turns it in to a poor man's CCA cable, running some FOSS software on the host will then enable to you stop the ME core on the target and modify memory at will. This basially enables a tethered ME jailbreak, but also ME malware persistence.
...only until someone finds a bypass for BootGuard, which might actually exist. I'm not too optimistic, but I hope so --- and seeing the reactions of different groups when/if it happens will be interesting to say the least.
We've been hunting for leaked keys, broken IBB's and ACM's for a while, but no real structural thing found so far.
There was a Gigabyte implementation that had a broken HOB response meaning you could boot even with unsigned firmware because the BootGuard handler always returned true. Then there was the lenovo one with BootGuard not even enabled, and there was one compal designed board that had BootGuard enabled but no keys fused. (MFG mode open as well)
Most of the implementation don't use Intel's reference with the logic bug, but an AMI or Phoenix or Insyde implementation.
But still hopeful to find a way to serve a bad ACM, mod the IBB (microcode update attack vector perhaps), or find a way to have the ME report fake values for the fuses (since the values are communicated buy the ME OS to the CPU).
CVE-2018-12169: Platform sample code firmware included with Haswell, Broadwell, Skylake, Kaby Lake, Coffee Lake and Cannon Lake processors contains a logic error allowing a physical attacker to bypass BootGuard firmware authentication. https://edk2-docs.gitbooks.io/security-advisory/content/unau...
"also potentially allows a developer to "jailbreak" their BootGuard protected laptop since the UEFI DXE volume can be replaced with a user provided LinuxBoot ROM image": https://twitter.com/qrs/status/1044157473882591233
Well, LinuxBoot is more like heads (the kernel based pre-boot environment), which was possible for a while now (because the DXE was often not required to be signed for BootGuard to be happy).
If we could do coreboot with only the FSP as blob, that would be cool. We'd still have the ME glued in tho, so not complete free booting there yet.
Also, sadly, most firmwares out there don't have that 1:1 edk2 code in their firmware.
It sure would be nice if we could just purchase such unlocked devices directly.
You used to actually control the devices you purchased. Then mobile comes along and so far we've seen locked OS accounts (rooting), locked bootloaders, and locked basebands. Now there's locked ME or PSP. This is getting ridiculous, as well as difficult to keep track of. Perhaps we need some sort of "Fully Unlocked" certification to indicate that a device you're considering purchasing would actually be yours?
> Perhaps we need some sort of "Fully Unlocked" certification to indicate that a device you're considering purchasing would actually be yours?
Maybe we should make it impossible to advertise a product as being purchasable if you also aren't purchasing rights to the software (and the ability to modify it). Just remove ownership from the equation entirely unless they can demonstrate that the user has full control of the hardware.
That would be a pyrrhic victory at best. True ownership of comsumer devices is de facto a thing of the distant past. If you degraded sales to rentals by law, manufacturers would immediately try to jump onto that train and come up with ways to extract even more momey from customers. How would you feel for having to pay your CPU manufacturer for the actual CPU time spent on your personal desktop computer at home? Of course, each core counts separately. Can't have you pay less for running properly paralellized programs, now can we?
"The "Respects Your Freedom" computer hardware product certification program encourages the creation and sale of hardware that will do as much as possible to respect your freedom and your privacy, and will ensure that you have control over your device. "
In other words, this vulnerability is "the insecurity that gives us freedom"? That's what it looks like from a quick scan through the article, and if that's the case this is yet another sad instance where the authoritarian "security" community is openly hostile against user freedom.
On that moral point, a relevant comment I made on an article recently: https://news.ycombinator.com/item?id=18102434 Anyone who is actively finding and closing local-only "exploits" for ME, ones which require root access in the first place, is being actively user-hostile.
"Freedom or persistent compromise" depending on whether it's the rightful owner or an attacker using the exploit. The most user-hostile part is forcing users to choose between accepting an OEM locked down platform, or running an open platform that an attacker can permanently lock down.
I'd happily pick the third option of running a platform locked down by me, the hardware purchaser, if it were ever made available to the general market. I have absolutely no objection to locked down hardware or DRM-like protections so long as the devices and software I'm using and installing obey me and only me.
Agreed, but I wasn't sure how to describe software that attempts to tightly restrict user actions, protect content streams, etc other than as DRM-like. Perhaps just "secure"? Someone controls the platform, and others (users, guests, adversaries, whoever) don't - I just want to be that someone if it's my device.
> The most user-hostile part is forcing users to choose between accepting an OEM locked down platform, or running an open platform that an attacker can permanently lock down.
That is flawed logic. The article demonstrates that the OEM version is insecure. Why would you assume that the open version would be more vulnerable to attackers?
>But finding these unpatched and vulnerable series of machines is a hit-or-miss game with minimum chance of success
Bios update version changes or the name itself mentions 'intel ME' in the manufacturer's site for their products[1] it should be fairly simple to find computers with an older bios version.
They also have a history of selling x86 systems while articulating vague hopes that the blob/owner control situation will improve in the future, despite this being clearly implausible. In one case for example, they claimed they might get Intel to sign a custom ME firmware for them in the future. Anyone who knows anything about the ME knows that Intel would never do this, ever.
I am not sure if seeking a “secondary processor” exclusion qualifies as "abuse". I agree that their products are not as "pure" as advocated by some enthusiasts. But the company itself openly says so and for me that is important.
What I do not like is their absolutely ridiculous pricing of additional equipment. For instance, they ask $499 for a 500GB NVMe storage [1], while it can easily be purchased for less than third the price [2]. When I complained about it, their response was: "we are well aware of the problem and will be addressing it within the next few months". That was 4 months ago.
The secondary processor exception exists for legitimate reasons. If you have some machine with 100% open source boot firmware, Coreboot, etc., that's still worth certifying even if some Ethernet chip turns out to have firmware inside it.
What Purism is doing is moving memory init code away from the CPU on which it would normally and most naturally execute (in terms of engineering design decisions) for the express purpose of moving something they can't actually open out of the scope of RYF. And are then brazenly admitting how they are gaming this in the above blogpost.
Most people would expect "open source firmware" to mean "open source memory initialisation", because we understand that's something the firmware does. Moving this onto a secondary CPU is literally no better than proprietary firmware. It can't be audited, and if it's able to initialise the memory controller, it can be expected to have full access to the system. They're practically carving out an Intel ME-like boot processor here, with much of the same disadvantages and concerns.
Isn't it fine as long as the secondary processor hands back once the initialization is done? Before the training the memory is unused, and only the "clean" processor has access to it after training. I can't see the threat.
Tangential: I noticed a similar issue with the pricing of SSD drives offered on Dell's Precision Mobile Workstation laptops.
Perhaps Dell's SSDs are extra-awesome in some manner that I'm failing to recognize. But otherwise it makes way more sense to just buy your own SSD drives for those laptops, AFAICT.
> They also have a history of selling x86 systems while articulating vague hopes that the blob/owner control situation will improve in the future, despite this being clearly implausible.
It’s not that implausible; the situation has improved considerably since 2014. They’ve managed to reduce the size of the blob on the ME processor considerably, to just that required for boot. That’s a pretty large increase in freedom, and a decrease in attack surface.
Even better, by getting those devices on the market, other vendors like System76 have been cajoled to follow suit in disabling the ME.
It’s not good enough for RYF certification, but it’s the best that you can buy on a laptop, outside of Librebooted ThinkPads from 2008.
I think a lot of people get annoyed by Purism’s lofty marketing and press releases, but they are actually doing great work.
I will also never trust Purism after their dishonest claims of having an entirely open laptop and entirely ignoring Intel ME problems for the sake of better marketing.
No they haven't. You can't "completely disable" the ME in modern Intel x86 laptops, it is literally instrumental in the boot process.
They can turn on the HAP bit and run me_cleaner, this reduces the amount of code which runs on the ME. This is an attack surface reduction. It is wholly misleading to refer to it as outright disablement of the ME.
Appears to mostly be an enterprise offering; I'm not quite sure if any of these companies would sell me a server for personal use. And even then I don't think I'd be able to request control over the various keys they're in control of (ie request the work be done to get me keypairs of my own, which I do think is theoretically possible).
This is bad in a DoS-type of way. BootGuard only loads correctly signed firmware, the root of trust is an Intel RSA keypair and the hash of the pubkey is burned into the CPU during Intel's manufacturing. The PCH (on the same chip in mobile cases) has the ME which also has fuses, and as long as the CPU only accepts signed code form the ME, and the ME has BootGuard fuse blown, the only thing you can really do is disable a system by nuking the SPI (or just flipping one random bit to invalidate the signature).
To fix it, you'd have to re-flash the SPI chip.
As far as I know, manufacturing mode only allows you to add signing keys if those keys are signed by Intel, so adding your own keys won't help. Adding a key from another manufacturer with known exploitable firmware could work, but loading that firmware on incompatible hardware won't let you boot the machine so you still get nothing.
All in all; nice find, yes you can disable machines via software, but other than that, not as interesting as I had hoped it to be. (IBB or ACM exploits would be very very very sweet)
It also means that instead of having to compromise Intel's signing key to gain full control, now it's also possible to use any compromised key that's been signed by Intel, which may not be as well guarded as Intel's one.
Yes, well, it was always possible (either using direct flashing or HDA_SDO), or by forcing a reboot with the upgrade bit set (which was enabled by default on most platforms I've seen up to 2017. (no real data after that since I no longer have to deal with fleets of random systems).
I suppose the ME MFG mode here adds for an additional path that can be abused silently, which is a real problem.
On the key side of things: I have not yet found a leaked key. That would have made coreboot life so much easier...
"The weakness of "security through obscurity" is so well known as to be obvious. Yet major hardware manufacturers, citing the need to protect intellectual property, often require a non-disclosure agreement (NDA) before allowing access to technical documentation. "
I believe the actual reason for "security through obscurity" is that it's a delay tactic used against well-funded adversaries.
There's an inherent problem in security. A company, existing in the private sector, could never hope to overcome the infinite resources of a nation state. It's literally, mathematically, financially impossible.
A nation state could even apply a rule like, if they know a particular technology was developed by roughly 500 engineers at some company, a nation state could employ 5x the number of engineers used; simply as a rule. So in this case, they could employ 2500 security researchers to overcome some security problem.
It's also possible to build systems that are correct, such that no adversary with any amount of resources could find a security hole. Many CPUs in the past have been correct. Probably most major commercial ones before 2000 were. So it's not mathematically impossible.
>Probably most major commercial ones before 2000 were.
I find that hard to believe. For instance, what makes you think they got speculative execution more correct before 2000 than after? At least it seems impossible to get rid of the timing side-channel since the whole point of the exercise is to change the amount of time it takes to run the program.
Surely you'd have to go back to at least 1980. I suppose one could start a production line of 1970s supercomputers for personal use, and put it on the programmers to figure out how to parallelise everything, but it would be very painful and expensive.
The beauty of public key cryptography is that a x5 increase in security researchers is nowhere near a x2^128 increase in difficulty. What's pitiful is coming up with O(1) schemes and hoping for security through obscurity to keep them safe.
NSA can't hire the hackers they want because they all smoke weed. China sends all their drug users to the execution van so all the new CS and security grads can go right to work for the govt.
I once worked with a guy who had previously worked for GCHQ doing something with cyphers/cryptography. He said he had never consumed more drugs in his life than during that period. They didn't care he took drugs as long as he was open about it and couldn't be black mailed through his use of drugs.
Interesting! Though GCHQ is UK, I'm not sure what the NSA is like. My impression so far here has been that they tend to hire people who live rather boring, quiet personal lives, since they're easier to vet.
I'm sure non-mainstream political views likely count against you more, though.
Also a lot of hackers/engineers have ethics that don't necessarily match that of government security agencies. I would happily work to protect my country from terrorism or foreign attacks, but not if it means sacrificing the freedoms that we were originally trying to protect.
Is there a way to enroll your own platform key on the latest UEFI Secure Boot enabled Macs? They do not include the 'Microsoft Corporation UEFI CA' therefore a bootloader signed by Microsoft's UEFI binary signing service (which most popular Linux distros do) cannot be verified. And that means you must disable Secure Boot to boot something other than macOS or Windows. And that means you don't really control, therefore don't really own, your hardware.
I remember several bunches of Lenovo laptop series released a few years ago seems to have the same vulnerability, and porting coreboot to those computers with earlier chipsets is a real possibility, only prevented by Boot Guard signature. But finding these unpatched and vulnerable series of machines is a hit-or-miss game with minimum chance of success. If someone really implements tools to do all these things, is it possible that the secondhand vulnerable motherboards would be the gold in the hacker communities and be sold at a high price?
Another fact is that ME is a part of the PCH, which is located on the CPU package. If a hacker has access to a BGA rework technician in a professional repair workshop, it should be possible to desolder the original CPU from the board, and install a new one with unconfigurated ME to "own" the machine.