
Intel ME Manufacturing Mode: obscured dangers and MacBook vulnerability - tomxor
http://blog.ptsecurity.com/2018/10/intel-me-manufacturing-mode-macbook.html
======
bcaa7f3a8bbc
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.

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

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

~~~
turblety
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)
    

Source:
[https://en.wikipedia.org/wiki/Intel_Management_Engine](https://en.wikipedia.org/wiki/Intel_Management_Engine)

I think there is also some power management functionality in there too.

------
walterbell
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](http://puri.sm)

2) Librebox is a desktop computer with coreboot, from Portugal,
[https://libretrend.com](https://libretrend.com) and
[https://youtube.com/watch?&v=mHyJCSqWhFw](https://youtube.com/watch?&v=mHyJCSqWhFw)

For data centers, OpenCompute server owners are also the "OEM" and in control
of more keys.

~~~
hlandau
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...](https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-
hurdle/)

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.

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

[1] [https://puri.sm/shop/librem-13/](https://puri.sm/shop/librem-13/) [2]
[https://www.amazon.com/Samsung-970-EVO-500GB-
MZ-V7E500BW/dp/...](https://www.amazon.com/Samsung-970-EVO-500GB-
MZ-V7E500BW/dp/B07BN4NJ2J)

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

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

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

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

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

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

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

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

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

