Experiments with disabling the ME on Sandybridge x230
coreboot.org
coreboot.org
That's pretty crazy to think there's a sub-ring-0 rootkit running on your CPU contacting NTP servers without your knowledge.
Does that work over wifi (where does it get the WPA password from)?
Where does it get an IP address? Does it leech off the host's DHCP IP by intercepting ethernet packets?
Is there any way to fingerprint the traffic? TTLs, sequence numbers, etc?
It'd be interesting to run a system behind a router for a while while logging all ME traffic...
This isn't something your consumer computer is doing automatically, in fact, your computer is almost certainly not capable because it lacks an AMT-capable NIC. I suspect the software capability is baked into ME itself rather than the AMT component so it's probably present in your ME, but it's not doing anything without an AMT NIC to communicate with.
This is the kind of feature that you pay an extra $1k for when you configure your $20k server.
We have ~$400 Sandy Bridge workstations at work that have separate AMT enabled NICs. You don't have to spend $1k for the feature; here's a vPro enabled board for $100:
http://www.newegg.com/Product/Product.aspx?Item=N82E16813157...
Dell's add-in card to do out-of-band management is called the DRAC and it's been optional in their servers for about 17 years: https://en.m.wikipedia.org/wiki/Dell_DRAC
https://defcon.org/images/defcon-22/dc-22-presentations/Kall...
and
http://legbacore.com/Research_files/HowManyMillionBIOSWouldY...
The example in the first link is especially depressing, because they found an integer overflow vulnerability in a code file that started with this warning comment:
/*
Caution: This module requires additional review when
modified.
This driver will have external input − capsule image.
This external input must be validated carefully
to avoid security issue like buffer overflow, integer
overflow. */
And of course, later someone came along and added an integer overflow.http://superuser.com/questions/360754/what-is-intel-active-m...
The fuses are blown when the chip is manufactured to encode a _pre-calculated_ 2048-bit rsa key-pair, selected from a giant collection which intel generated en-mass to have some properties that allow the two 1024-bit primes to be encoded using only 272 bits each (if I'm reading it right):
"The TPM on the security and management engine features a preinstalled endorsement key (2048-bit RSA). The endorsement key is required to be unique per hardware part. Because of its uniqueness, the endorsement key cannot simply be hard-coded in the firmware, which is the same on all parts. Instead, hundreds of millions of endorsement keys are pregenerated. During Intel’s manufacturing process, different key materials are burned to the platform’s security fuses for all parts, respectively. Note that key materials are not the key value. [...] This algorithm is implemented by the key generation facility and not the TPM firmware."
(Same source as parent)
https://www.coreboot.org/pipermail/coreboot/2016-September/0... - "AFAIK the ME will allow the platform to stay on for 30 minutes, and will then shut it down hard." (when the firmware/ME has gone bad)
https://www.coreboot.org/pipermail/coreboot/attachments/2016...
If this will turn out to be something that could be reliably disabled on other laptops, this is going to be huge.
I built a headless compile-slave box recently, and was looking forward to using AMT features to manage it and keep it headless, but found out too late that the board I ordered didn't have AMT support. Now, whenever its fragile boot-stack of GRUB+iSCSI+Xen+LVM decides to wedge into single-user mode on a reboot, I have to power the box off and carry it over to a monitor to see what's wrong. I'd much rather just fix it from my laptop.
You can disable SuperMicros IPMI though by pulling out the PCI card, though :-)
Once you have a serial console, you can either just plug the cable into your laptop (likely through USB-attached serial port) or set up a small second box (that just runs an ssh daemon and has something like picocom installed) and connect it to that. Then you'll have access over the network.
As long as the actual owner has the keys, I agree.
Highly recommended read about x86 security: http://blog.invisiblethings.org/papers/2015/x86_harmful.pdf
The author of this paper is also the developer of Qubes OS. They recently added another requirement to laptops who are 'Qubes certified': they must run Coreboot. It's not Libreboot yet, but that is a huge leap forward for x86 security. Hopefully this will trigger vendors to make their hardware Coreboot compatibile. It won't do anything about Intel ME, but it is a step in the right direction.
I ordered a Thinkpad x200 to flash it with Libreboot last week, just to have at least one device without any malware (in RMS sense)
Or Novena? https://www.crowdsupply.com/sutajio-kosagi/novena
No?
Well, let me take a step back and first say that the project is impressive and I really like it.
But the cost is staggering.
"We're in talks with Intel" "They really want to do this" "We're going to make a petition to show interest to Intel"
The reality is that even Google with their Chromebooks, despite hiring most of the Coreboot team and shipping volume into the likely millions of units, was unable to persuade Intel. Even for the absolutely tiny set of CPU models they use
It's a bit over-the-top paronoid to expect firmware modifying software in GPU drivers, but I understand their point.
Broadcom publicly released some code, licensed as 3-Clause BSD, to aid the making of an open source GPU driver. The "rpi-open-firmware" effort to replace the VPU firmware blob started in 2016: https://github.com/christinaa/rpi-open-firmware. See more at https://news.ycombinator.com/item?id=11703842
The sad thing is that ME isn't even developed by Intel, but a third party. They sublicense it to Intel. So even if Intel would be willing to distribute the source, they couln't.
TBH, I think there is a lot of focus on this ME technology and I see no reason that at some point someone is going to crack the model or the encryption and reveal exactly what it is doing and how to disable it.
Isn't x64 a standard? Couldn't another company create their own implementation of it and design their own processors for the paranoid to use?
The problems are economies of scale and the perfect being the enemy of the good. What is the interest in an expensive custom chip when you still can't trust that it wasn't compromised by the fab?
With testing amplification, you can then set an upper bound on the probability that the chip will run a backdoor.
You're only locked in if your personal requirements mandate the smallest lithography process and the highest clock speed.
Also, the Microsoft Surface RT tablets were ARM and fairly impressive from a hardware standpoint (sturdy, nice screens, etc.) You should be able to get a used one on Swappa fairly cheep. I know there was some credential leak recently, but I'm not sure if that's gone far enough to make it a useful development machine. (Also, it's a tablet with a kickstand and a detachable keyboard...)
Where does one find a MIPS or ARM laptop? Who manufactures them?
I'm pretty sure POWER still fulfills requirements for "highest clock speed", not x86/x64. That might be based on outdated information, though; I just recall POWER being the first to hit 5GHz CPU clock speeds even in spite of IBM's lithographic processes lagging behind Intel's.
Even if it was, being a standard does not mean that it is free, easy and legal for others to implement. Some standard bodies require a patent sharing agreement or licenses being provided for a "reasonable" cost, but what is reasonable is often a topic of discussion.
x86_64 also incorporates a 32-bit compatibility, which is copyright protected by Intel and only a handful of licensees exist, with no new licenses having been signed in the past decade or so. I don't think you can implement AMD64 without also acquiring an x86 license from Intel.
x86_64 is an AMD standard, I believe still under patent.
Intel and AMD cross-license these patents to each other. As a result, any other company wanting to make x86 processors would have to purchase rights from both companies (assuming they're willing to, which is a big if), which would instantly make their products cost-uncompetitive.
x86 is also copyrighted, but it's expired. Most the parents have expired and it's starting to become more common to 486 and 386's in very cheap embedded controllers.
Wow. This is part of the processor?
Luckily the implementation is obscure so it has perfect security, right? There's no way such a complex piece of software that has had very little oversight could have exploitable bugs that would completely destroy any security foundations you have on your machine.
And appears to be built to do so out of the box by default with no "specialized code". I'm guessing with both wired and wireless interfaces... crazy!
http://boingboing.net/2016/06/15/intel-x86-processors-ship-w...
I'd love to get a look at what it's doing.
So 1) will the system stay up with the ME software erased, 2) what's the ROM component doing besides managing the boot, and 3) what access does it take to alter the ME's firmware?