Live data from Hacker News

Intel ME Manufacturing Mode: obscured dangers and MacBook vulnerability

blog.ptsecurity.com

71–80 of 85 posts

Re: Intel ME Manufacturing Mode: obscured dangers and MacBook vulnerability

#71
post #66

Earlier quoted context omitted.

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 thi…

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 pur…

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.

Re: Intel ME Manufacturing Mode: obscured dangers and MacBook vulnerability

#72
post #57

Earlier quoted context omitted.

OpenCompute look interesting on the surface, but it seems like the "server owners" listed at https://www.opencompute.org/sp/open-compute-project-solution... consists of mostly larger corporations. 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…

Used ones show up on eBay. Don't know about their firmware key management status. https://www.reddit.com/r/homelab/comments/4f7w82/4node_open_...

Wow, that's impressive pricing. And two years ago too. Adds to bookmarks

Re: Intel ME Manufacturing Mode: obscured dangers and MacBook vulnerability

#73

Earlier quoted context omitted.

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…

...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.

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

Re: Intel ME Manufacturing Mode: obscured dangers and MacBook vulnerability

#74
post #46

A couple of small vendors are trying to offer choices with open firmware. They don't yet have the scale for low cost pricing. 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 own…

Purism is a sham. They are openly trying to abuse the RYF process to get a phone with proprietary firmware blobs certified as "RYF", defeating the entire point of the RYF programme: https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd... 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 im…

> 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.

Re: Intel ME Manufacturing Mode: obscured dangers and MacBook vulnerability

#75
post #45

Earlier quoted context omitted.

> 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 y…

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 sy…

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

Re: Intel ME Manufacturing Mode: obscured dangers and MacBook vulnerability

#76
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.

Re: Intel ME Manufacturing Mode: obscured dangers and MacBook vulnerability

#77
post #40
post #14

Earlier quoted context omitted.

> 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 th…

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 co…

> That would be a pyrrhic victory at best. True ownership of comsumer devices is de facto a thing of the distant past.

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.

Re: Intel ME Manufacturing Mode: obscured dangers and MacBook vulnerability

#78
post #20

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 disabl…

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...

Re: Intel ME Manufacturing Mode: obscured dangers and MacBook vulnerability

#79

Earlier quoted context omitted.

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…

...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).

Re: Intel ME Manufacturing Mode: obscured dangers and MacBook vulnerability

#80

Earlier quoted context omitted.

>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 doin…

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 use…

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.

Post reply on HN