
Intel and ME, and why we should get rid of ME - protomyth
http://www.fsf.org/blogs/licensing/intel-me-and-why-we-should-get-rid-of-me
======
e12e
Intel remote management with support for using the wireless card is something
that got me quite terrified when I first tried on my T420. Basically, no
recent intel laptop can ever be secured, unless you physically remove the
wireless and wired network card.

Intel has a jolly video demoing how to pwn a machine remotely (framed in the
positive light of taking control and fixing a boot problem by the it service
desk):

[http://www.intel.com/content/www/us/en/remote-
support/remote...](http://www.intel.com/content/www/us/en/remote-
support/remote-support-vpro-easy-operating-system-reimaging-video.html)

This is for 6th generation+ cpus, but the systems in older cpus are also quite
powerful. And can't really be protected beyond using a password/passphrase.
I'm not sure (and probably no-one knows) if there's also a golden
key/backdoor.

(I wonder if the video is actually narrated by Zach Woods (Donald 'Jared' Dunn
from Silicon Valley) - or if it just sounds a bit like that).

At any rate, if watching that jolly video doesn't fill you with fear, I'd say
you're not sufficiently paranoid.

~~~
eeZi
You can disable the remote management and the entire embedded network stack
though.

~~~
ZenoArrow
That's not so easy to do. To get a sense of what's required...

[https://software.intel.com/en-us/forums/intel-business-
clien...](https://software.intel.com/en-us/forums/intel-business-client-
software-development/topic/563988)

Plus, even you disable it there's still room for exploits, previous versions
of Intel AMT have had exploits. Check out the 'Known vulnerabilities and
exploits' section of the Intel AMT Wikipedia page:

[https://en.m.wikipedia.org/wiki/Intel_Active_Management_Tech...](https://en.m.wikipedia.org/wiki/Intel_Active_Management_Technology)

~~~
luma
Enabling it isn't generally easier either, and it can be secured with
certificates on both side. Every time this topic is brought up I'm surprised
by the number of people who think remote access is bad and cannot possibly be
secured, while not actually digging into what it would take to compromise such
a machine.

Maybe it's the server admin in me, but OOB BIOS-level remote access and
management for my systems is a godsend and my biggest issue with it is that
they tend not to include those features in their "enthusiast" chipsets.

~~~
ZenoArrow
The features are included in all modern Intel CPUs AFAIK, if you found one
where it wasn't included please let me know as its absence would be a feature
for me.

As for the number of people who think remote access is bad, nobody seems to be
denying it can be useful, but by baking it into hardware you're basically
hoping that it doesn't get hacked. If it was an optional dongle nobody would
care.

~~~
luma
The remote access part is called AMT[1] and is part of the Intel vPro[2]
feature set. It most certainly is not enabled in all modern Intel processors.
Further, it requires a compatible processor, chipset, and BIOS for it to be
enabled.

There is a common misunderstanding in these discussions that the ME features
of the Intel processor (included in nearly all modern procs) allows for
hardware level remote access, which isn't true.

[1]
[https://en.wikipedia.org/wiki/Intel_Active_Management_Techno...](https://en.wikipedia.org/wiki/Intel_Active_Management_Technology)
[2]
[https://en.wikipedia.org/wiki/Intel_vPro](https://en.wikipedia.org/wiki/Intel_vPro)

~~~
dlmetcalf
Yeah, right. I suppose we're just supposed to take their word for that.
There's an enormous difference between the concepts of trusted and
trustworthy. You're extremely naive or clearly never read anything Snowden
released if you think 'trust us' is enough.

~~~
luma
Are you suggesting Intel has implemented hidden backdoors into all of their
systems?

~~~
livus
Not OP but it could be very much possible and that's what OP is trying to say.
Just taking it on Intel's word that they haven't done it is not the correct
way to go. For the truly privacy minded, it's better to err on the side of
caution.

~~~
luma
Err on the side of caution in this sense would mean fabricating your own proc.
Are you going to do that?

~~~
colejohnson66
How do you know the fab you send your design to doesn't implement a backdoor?
You have to have trust at SOME level.

~~~
luma
That is exactly my point. If you don't trust Intel, then who are you
suggesting should build your processor? Unless you are going to design and
fabricate your entire system top to bottom, and have no other persons involved
who could surreptitiously insert evil code, then you're going to have to
accept some degree of trust in a 3rd party.

~~~
dlmetcalf
It's not just Intel you're trusting, it's the OEMs, who also have an EXTREMELY
poor record. Just take a look at the ENORMOUS number up BMC and auto-update
vulnerabilities. They really just either couldn't care less, or are
deliberately making machines vulnerable. Things are being pushed into IME,
that aren't optional, often aren't wanted by users (or snuck in there so they
wouldn't know), don't all have to be there, can't be verifiably disabled or
overriden by end users. Even if it weren't backdoored (unlikely), it presents
an ENORMOUS attack surface at the very worst possible privilege level. Open
source designs that are at least inspectable by researchers would be a start.
But more importantly - allowing users to CHOOSE whether they want to override
software (it IS after all software and not hardware). Why shouldn't we be
permitted to run Libreboot etc on modern hardware and know that when we turn a
machine off, that it's off, without unplugging network, power cables,
batteries, etc?

------
dlmetcalf
Wow, no one here has mentioned Johanna Rutkovska's (Invisible Things Lab &
QubesOS), "Intel x86 Considered Harmful"?

[http://blog.invisiblethings.org/papers/2015/x86_harmful.pdf](http://blog.invisiblethings.org/papers/2015/x86_harmful.pdf)
[http://blog.invisiblethings.org/2015/10/27/x86_harmful.html](http://blog.invisiblethings.org/2015/10/27/x86_harmful.html)

Essential reading!!

[https://www.youtube.com/watch?v=rcwngbUrZNg](https://www.youtube.com/watch?v=rcwngbUrZNg)

~~~
dcposch
Joanna is a hero.

Also, I would give anything for a clean slate design that prioritized
simplicity and transparency.

We've been layering complicated crap under and on top of older complicated
crap for so long that even professional engineers no longer understand exactly
what happens when you push the power button.

As long as that is true, we will never be secure.

~~~
dlmetcalf
Totally agree. She's brilliant. Deepest respect to her.

One of the extremely few people with genuine understanding of hardware
security, who's working on the side of users & humanity.

The first time I read her work, I was floored that I hadn't known of her
earlier.

------
rxm
There was another thread on ME. At some point ME will get hacked or the golden
certificate stolen, at which point someone will have a lot of access.

[https://news.ycombinator.com/item?id=8813029](https://news.ycombinator.com/item?id=8813029)

~~~
imbellish
> My first thought was that it seems increasingly clear that Stallman has been
> right all along. The problem is that being philosophically right doesn't
> always mean being practically right. In order to create the perfect
> Stallman-esque machine, one would have to design everything from the logic
> chips up from scratch, because in the end, no third party can be trusted. He
> says this himself about the Loongson system he uses daily; he considers it a
> compromise but one heavily weighted in his favor. In short, Stallman has
> been right all along, but there's little we can do about it from a practical
> standpoint.

Cherry-picked from that thread. I just have to point out this awful slippery-
slope argument.

~~~
brianwawok
Just because we list slippery slope as a fallacy, does not mean it never
happens like that.

Basically Intel owns the desktop and server market. They sneak stuff in that
we may not want. What can we do at this point?

~~~
dlmetcalf
Vocally support Power8 and RISC-V projects and ensure Intel knows you're
angry.

~~~
colejohnson66
Like what happened with the NSA? Not to be rude, but you can be vocal all you
want, but as long as the majority of the public doesn't care, there's not much
you can do.

------
dlmetcalf
I hope these guys get lots of orders and prices fall (Raptor's Talos Secure
Workstation):
[https://www.raptorengineering.com/TALOS/prerelease.php](https://www.raptorengineering.com/TALOS/prerelease.php)

With Google having ported all their software to Power8, I'm looking forward to
more economies of scale kicking on.

~~~
BuildTheRobots
It looks great, except it has a ASpeed AST2400 BMC on the board which seems to
do video and usb over IP etc (edit: eg it ties into networking, pci, usb,
memory)...

Unless the firmware running on the BMC is going to be open source, I fail to
see how it helps.

~~~
dlmetcalf
Does this cover your concerns?

    
    
      Open-toolchain FPGAs
      Blob-free operation
      - Fully libre (open-source) IBM OPAL primary firmware w/ PetitBoot interface
      - Fully libre (open-source) OpenBMC secondary (IPMI / OoBM) firmware
      NO signing keys preventing firmware modification

~~~
BuildTheRobots
Gets most of the way there, though I'm confused as to the wording on the BSC.
"Fully libre OpenBMC _secondary_ firmware". Still slightly worried as to the
meaning of Secondary firmware; almost makes me think the BSC has non-libre
_primary_ firmware on there too.

------
slasaus
FWIW, there is a petition for Intel to Release an ME-less CPU design:
[https://puri.sm/posts/petition-for-intel-to-release-an-me-
le...](https://puri.sm/posts/petition-for-intel-to-release-an-me-less-cpu-
design/)

------
mrob
I don't see how getting rid of the ME helps. If you don't trust Intel then you
don't trust Intel. They can backdoor the main CPU as easily as they can
backdoor the ME. The only true solution is an Open Source Hardware CPU, and
some means of verifying that the hardware matches the HDL.

There are already Open Source CPU designs, but the verification is more
difficult. Even if you use a big enough process node that you can decap it and
inspect it optically (eg. using similar techniques as used with
[http://visual6502.org/](http://visual6502.org/) ), there is still the
possibility of dopant-level backdoors which are much harder to detect:

[http://sharps.org/wp-content/uploads/BECKER-CHES.pdf](http://sharps.org/wp-
content/uploads/BECKER-CHES.pdf)

~~~
edwintorok
Trusting Intel on producing a CPU, and trusting Intel with ME are completely
different levels of trust. If I could run my own software on the Intel ME, I
wouldn't mind.

In some sense having Intel ME is worse than having Windows as your OS: at
least you can apply security patches for Windows, and should you choose to do
so you can replace it with your favourite OS. However Intel ME is entirely
closed source and locked down: probably running out-of-date software with
several unpatched vulnerabilities with no way for the user to inspect it,
patch it, turn it off with a jumper or replace it.

~~~
yuhong
AFAIK they can patch the Intel ME firmware and often do with BIOS updates. I
am not sure about AMD PSP but that don't have access to the network so
patching it is less important.

------
DenisM
I often wonder if the only secure computing and communication these days is an
air-gapped computer.

The data can be manipulated there and then copied to another computer using...
uh... a writeable compact disk? USB drives are hard to trust given how much
software is running on them, so... maybe CF cards too?

~~~
pdkl95
You want data diodes that physically enforce one-way-only data transfer.

Tin Foil Chat[1] has a circuit for an opto-isolator based data diode and a
discussion of how to use them for secure chat. It's probably not hard to
modify these plans for other uses, if the specific guarantees that TFC
provides are compatible with your secure computing requirements.

[1]
[https://cs.helsinki.fi/u/oottela/tfc.pdf](https://cs.helsinki.fi/u/oottela/tfc.pdf)

~~~
nickpsecurity
It's not hard to adapt. He regularly improved it based on our feedback at
Schneier's blog. I speculated that a higher bandwidth would allow audio and
video using same architecture. It's a great desigm regardless due yo strong
confidentiality despite endpoint attacks.

------
boznz
Scary, I did not know this

I'm sure Intel has a real good reason for it being there but I would feel much
more comfortable with it either not being there or being able to disable it in
hardware.

~~~
catnaroek
I'm not sure what that “good reason” could possibly be.

~~~
PeCaN
It's known to be used for DRM.¹ So… not a good reason, but at least it makes
sense. Then there's Intel's very likely cozy relationship with the NSA.² ³ ⁴ ⁵

\--

¹ [https://libreboot.org/faq/#intelme](https://libreboot.org/faq/#intelme) See
paragraph 6.

²
[https://plus.google.com/+TheodoreTso/posts/SDcoemc9V3J](https://plus.google.com/+TheodoreTso/posts/SDcoemc9V3J)

³ [http://www.eteknix.com/expert-says-nsa-have-backdoors-
built-...](http://www.eteknix.com/expert-says-nsa-have-backdoors-built-into-
intel-and-amd-processors/)

⁴ [http://www.infowars.com/intel-ceo-refuses-to-answer-
question...](http://www.infowars.com/intel-ceo-refuses-to-answer-questions-on-
whether-nsa-can-access-processors/) (Note the NSA slide.)

⁵
[https://www.reddit.com/r/IAmA/comments/1ycs5l/hi_reddit_im_b...](https://www.reddit.com/r/IAmA/comments/1ycs5l/hi_reddit_im_brian_krzanich_ceo_of_intel_ask_me/)
(No hard evidence, but he dodged basically every question related to the NSA.)

~~~
amluto
> It's known to be used for DRM.

Better citation needed. AFAIK the ME has never been used for DRM. It's
supposedly used to implement TPM 2.0 aka PTT, but AFAIK that has never been
used for DRM either.

~~~
ogn3rd
ME also controls the feature set available to the storage controller. I.E.
whether or not it can support RAID 0, 1, 5 natively. Its features can be
updated via BIOS firmware, which has to correspond to whats baked into the
CPU. It can be bypassed using a special version of BIOS firmware in
combination with a cpu with the right fuses blown. It almost takes an act of
god to get all those things, even in their lab, when you're getting paid to
test it.

~~~
amluto
Really? That surprises me.

AFAICT Intel's desktop RAID tech literally just remaps PCI vendor and device
ids (which is a wee bit more complicated with NVMe / AHCI over SATA Express).
The boot process was an option ROM and is presumably now baked into UEFI. The
driver does the rest.

I can imagine that a couple bits in ME tell the UEFI blob and the driver which
feature set to enable. Is there more?

------
hueving
>Libreboot X200 laptop

Is this laptop the top of the line spec-wise that you can buy which is free
from this trash?

~~~
spash
Semi-hijacking your question to mention the other side of the pond too, which
many people do not seem to know about and I run into this issue quite
regularly.

While the laptop situation is indeed pretty bad (the X200 is probably as best
as you can get here), for people looking for a modern workstation, AMD's
current FX processor lineup is still free from this trash. Past the 2013
designs (Family 16h [1]) AMD includes their own equivalent of Intel's ME
called PSP [2], so presumably the upcoming Zen is going to be heavily
backdoored too.

Now, you can still buy an 8-core/4 GHz+ AMD Vishera [3] generation (which is
the "current" FX), add a motherboard with ECC support (in a stark contrast to
Intel, all AMD FX processors fully support ECC memory and for example ASUS
sells a number of AMD motherboards with ECC support) and build yourself a
workstation that will easily last for another decade, possibly longer (you can
always buy a motherboard or two of your favourite model as a backup for the
times when they finally disappear from the market). All FX processors are
factory unlocked [4] and can be pushed much farther past their design specs
with decent cooling, adding another bit to their possible usefulness over the
long term.

Some more (random) reading on the subject of avoiding AMD PSP and Intel ME:

[http://hollaforums.com/thread/557954/technology/uncorrectabl...](http://hollaforums.com/thread/557954/technology/uncorrectable-
freedom-and-security-issues-on-x86.html)

-

[1] -
[https://en.wikipedia.org/wiki/List_of_AMD_CPU_microarchitect...](https://en.wikipedia.org/wiki/List_of_AMD_CPU_microarchitectures)

[2] - [https://libreboot.org/faq/#amd](https://libreboot.org/faq/#amd)

[3] -
[https://en.wikipedia.org/wiki/List_of_AMD_FX_microprocessors...](https://en.wikipedia.org/wiki/List_of_AMD_FX_microprocessors#Piledriver-
based)

[4] - [http://www.techpowerup.com/153445/amd-unlocked-fx-
processors...](http://www.techpowerup.com/153445/amd-unlocked-fx-processors-
announced)

~~~
yuhong
I should also point out however that AMD PSP don't have access to the network.

------
35bge57dtjku
Can I just use AMD chips to avoid this?

~~~
anonbanker
AMD has it's own secret firmware. it was shown off a year or two ago at Chaos,
and AMD only allowed the presentation to happen if they had a PR rep onstage.

~~~
daxorid
Indeed. And even ARM has TrustZone. Our governments own us. Just accept it.

~~~
anonbanker
TrustZone doesn't really look like Management Engine at all. Are there some
documents comparing the two?

(Heavily invested in Rockchip/MediaTek chipsets. Less scared of chinese
backdoors than FIVE EYES backdoors.)

~~~
ZenoArrow
You're right to question this, as TrustZone isn't equivalent to Intel ME.

To explain further, here's a comment I made about this before...

[https://news.ycombinator.com/item?id=11290069](https://news.ycombinator.com/item?id=11290069)

------
orik
BLK overclocking non-k sky lake chips disables ME. You loose out on some power
saving/voltage throttling features as well as avx2 instructions, but if you're
worried about security ME is disabled.

~~~
lfam
Can you provide a reference for this?

------
pmarreck
After the demise of PowerPC in the general computing space, what did you
expect would come of Intel hegemony? BS like this. An invisible, all powerful,
potentially hackable layer between the chip core and the OS sold as something
to ease remote administration and enforce DRM.

------
SFJulie
Problem of security product is their designers often do shitty code with
design flaw with very high privileges.

But be assured every thing is fine since for security reasons you cannot see
their code.

------
gpvos
Does ME still access the network if you don't connect anything to the Intel
network card, but use a different network card instead?

------
hornbill
How does Intel ME access network? Does it use the IP address assigned to the
OS or does it try to get perform DHCP?

~~~
yuhong
It has to be configured to enable Intel AMT to do that, and that is if the
firmware edition that has the code is installed (which I don't think is always
the case). It is useful in enterprises that want remote management. It
probably uses DHCP by default.

~~~
hornbill
I did not find anything about ME in BIOS settings, probably the code is not
present as you suggested. I have not seen any DHCP requests from the box.

~~~
unixhero
My brand new Thinkpad T550 has an explicit ME config firmware I can enter.
PRESS ENTER TO INTERRUPT BOOT -> F1 BIOS, F12 CUSTOM BOOT DEVICE, F9 INTEL ME
SETUP

I can enter into it but its vital parts are password protected. Even though it
is my computer, I cannot configure and control it. Scary. This is not the
future I wanted.

~~~
andreyv
The default password is "admin".

~~~
unixhero
Nice one! Will try that.

~~~
cm3
Did it work?

~~~
unixhero
It accepted the password, though all uppercase "ADMIN". It then immediately
wanted to set a new password, which fails every time. Possibly an undocumented
password strength policy, but could be anything.

------
microcolonel
I look forward to the variety of vendors who will offer RISC-V chips in the
coming decade. I love Intel's approach to graphics and other drivers on Linux,
they've been very helpful, and their products do often work well; however I
don't think that I can bear the societal cost of something as misguided as the
Management Engine. I'm perfectly happy to miss out on DRM'd consumer content
on my workstation; I'm not happy to miss out on decent security principles.

------
MichaelGG
How is this enabled though? Sounds like ILO/DRAC/etc., if a bit more capable.
But if it's not turned on, is it that big of a deal?

If we assume Intel is malicious, they hardly need a platform like ME to do
harm. And isn't this kind of stuff only available on the more expensive
systems? Because they include this to sell to enterprise help desks, right?

I dislike articles that seem set to spin something. At least explain the
plausible or documented reasons, then show why it's bad.

~~~
Kliment
Don't assume malice in this case, assume incompetence. And ME is on basically
every intel processor made in the past 8 years

------
Qantourisc
Intel should supply a ME bricking firmware !

~~~
ogn3rd
turning it off required a special cpu with the right fuses blown, along with a
special firmware version. it's baked into the cpu logic.

------
csense
Anyone know if AMD suffers from a similar "feature"?

------
omphalos
It's remarkable how a company with so many resources can make something so
poorly designed.

------
uudecode
Generally, do development boards have ME, too?

------
_yosefk
Prediction: over time, there will remain no commercially significant high-end
chips without this sort of a "security subsystem." Recommending ARM, PowerPC
or other architectures over x86 as the FSF suggests will not get you very far
because the problem (or as chip vendors call it, the solution) is not in the
ISA, it's in the chip, and every chip vendor making the sort of chip that can
power a general-purpose computer will end up being this way.

Of course in practice, as long as say Linux runs on the machine, the existence
of the ME or the like is almost inconsequential for the user, because you run
the same software, and there's never a shortage of security vulnerabilities
right there in the OS and the userspace software. In terms of the impact on
the number of vulnerabilities, eliminating C and C++ would go way further than
eliminating black box "security" hardware, just because the huge amount of C
and C++ code, much of it written hastily and committed the moment it "runs on
my machine", presents a much larger attack surface than the black box hardware
+ software system. But of course the FSF will never recommend ditching C and
C++.

~~~
joosters
Well done for turning an unrelated issue into a C++ rant!

~~~
_yosefk
Do you think the keylogger running on your and my machine came in by
exploiting the ME or a C buffer overflow somewhere in the OS or userspace code
that sister claims you "control"?

~~~
reality_czech
"Luckily," we don't have to choose between being afraid of firmware and afraid
of C and C++. The shitty Management Engine and other firmware code will be
written in C or C++ by terrible coders. The UEFI source code is over 7000
files and 100 MB of code, according to Matthew Garret:
[https://www.linux.com/learn/uefi-secure-boot-big-hassle-
ques...](https://www.linux.com/learn/uefi-secure-boot-big-hassle-questionable-
benefit) . And it can continue running once the OS has booted now (a great
"feature" that was missing from the BIOS, right?)

~~~
yuhong
Intel ME is a blob written by Intel however and all OEMs uses the same one.
I'd bet on UEFI code being worse than the Intel ME firmware.

~~~
reality_czech
Isn't this kind of like arguing over which brand of hot dog has more pink
slime and factory floor sweepings? They all do.

Anyway, ME is likely to be a much higher value target for hackers. A
compromise there would compromise millions of PCs, whereas a UEFI hack would
be specific to one vendor.

~~~
yuhong
Obviously, but UEFI tends to cause more of the practical problems and attacks,
including non-security ones and DoS attacks (some of which is easy to do under
Windows).

