Intel ME Manufacturing Mode: obscured dangers and MacBook vulnerability
blog.ptsecurity.com
blog.ptsecurity.com
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.
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.
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.
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.
We shouldn't excuse them so readily.
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.
You're assuming (fully) rational actors. It's fairly easy to have blindspots when they are (at least temporarily) useful.
Source?
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.
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.
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).
MINIX is a completely different OS than Linux, not a flavor of Linux.
“MINIX Linux” makes as much sense as “MacOS Linux”.
Intel ME just runs MINIX.
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.
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.
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.
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)
I think there is also some power management functionality in there too.
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?
Either way, you got a sad laugh from me.
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.
Only because consumers are not offered an honest choice.
Anyway buying by the cycle would fall squarely into non-ownership, would it not?
In any case, this type of pessimism IS a clear loss for consumers.
"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. "
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.
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?
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.
"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
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.
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).
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.
[1] : https://www.acer.com/ac/en/IN/content/support-product/6752?b...
1) Purism has been discussed on HN, trying to extend their laptop coreboot success to a phone form factor, http://puri.sm
2) Librebox is a desktop computer with coreboot, from Portugal, https://libretrend.com and https://youtube.com/watch?&v=mHyJCSqWhFw
For data centers, OpenCompute server owners are also the "OEM" and in control of more keys.
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.
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.
[1] https://puri.sm/shop/librem-13/ [2] https://www.amazon.com/Samsung-970-EVO-500GB-MZ-V7E500BW/dp/...
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.
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.
https://puri.sm/posts/purism-librem-laptops-completely-disab...
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.
That's a big stretch. Purism does a lot of work, openly, to try to disable ME.
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.
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).
Hmph.
https://www.reddit.com/r/homelab/comments/4f7w82/4node_open_...
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)
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...
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.
I'm sure non-mainstream political views likely count against you more, though.
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.