For this NTP check to happen, you must be using a computer with Intel MEBX and an Intel AMT-enabled network adapter, and the network adapter must be configured with network information to use. You have to do this manually initially, although of course later you can configure AMT using AMT.
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.
> 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:
Not specifically ME but yeah Baseboard Management Controllers and IPMI modules have been a thing for a long time. Most real server motherboards have them or have the facilities in place to accept them as an add-on module. It's not even just stuff in the $20k range; this $450 mini itx 8-core Atom-based storage server board has it: http://www.asrockrack.com/general/productdetail.asp?Model=C2... and it comes with a web-based IPMI console. You can turn the power on and watch it POST with a java web screen viewer, sending it keys as if you were sitting there.
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
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.
ISBN 9781430265719: "To get the current date/time information, the EPID manager requests a real-time OCSP (Online Certificate Status Protocol) response from a trusted OCSP server, which was endorsed by Intel. The response contains the current date/time. The EPID manager saves the date/time (baseline) in a file in the kernel’s secure storage and calls the kernel’s Start timer function that starts the timer. Later, when the EPID manager is verifying the validity period of a certificate, it calls the Get current timer value function and calculates the current date/time by adding the kernel’s returned value to the baseline. The EPID manager requests a new real-time OCSP response every 30 days to calibrate its timer."
Tangental, but interesting in a The-Dystopian-Future-Is-Now! sense: "The endorsement key initially placed in security fuses may be revoked by the TPM2_ChangeEPS command introduced in TPM 2.0. In this case, the TPM must generate a new endorsement key pair, store it in nonvolatile memory, and remember not to use the one in the security fuses in the future. The TPM task uses a field programmable fuse for the purpose of saving the revocation status of the endorsement key in fuses."
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."
Heck, it would be big news even if this applied only to the x230. Or even if it only applied to some x230s. It means there's a somewhat modern x64 laptop on which the ME can be disabled.
As much as people are freaked out by the capabilities of ME, I really like the concept of AMT.
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.
These kinds of features are standard for servers and nobody bats an eye ("out of band management"). You need them unless you want to attach a remote KVM to every single server. AMT is just that - out of band management. Intel's implementation is a lot more secure than, say, SuperMicro IPMI which had its fair share of issues.
You can disable SuperMicros IPMI though by pulling out the PCI card, though :-)
Why can't you attach a serial console? This will help with any problems that still let you get to grub (BIOS Setup likely doesn't support UI over serial, unless it's a server-like machine).
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.
The capabilities of an out-of-band management system are much, much greater than the serial console offers. BIOS and UEFI configuration are an obvious case, but you also use out-of-band management to bail yourself out of situations where the OS is unresponsive or unbootable, and to take many other management actions that would normally require physical access.
Serial consoles don't help if the box is properly wedged, or has eaten its own bootloader. With a good out of band management system, you can install an OS remotely, with disks on the session driving it appearing as local disks to the machine. Or, you can power off a box as needed, power it on, reconfigure raid cards, etc. A remote serial console is very limited in comparison.
It's a shame that ME can't be removed or disabled on modern Intel CPU's. Same goes for AMD and maybe companies that implement something like ME in ARM. OpenSPARC is quite dead, sadly enough.
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)
I've got a couple of Novenas. It's good for development except for web-browsing; for whatever reason firefox and chromium are both pretty sluggish on it. Everything else seems fine; I suspect that it's mostly down to video drivers, which are still somewhat in a state of flux (but getting better).
I'm skeptical about whether the video drivers are the culprit for poor web browsing performance. Yes, there's WebGL, but do Firefox and Chromium depend that critically on OpenGL for rendering ordinary web pages?
There's zero chance that the future Librem laptops will be "truly" open source. They will still have ME or AMD equivalent. Their entire marketing campaign is frustratingly dishonest.
They're quite competent con men. If you call them out about it (as the Coreboot developers did) especially on Reddit, they give very dismissive, yet non-committal comments
"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
I have an x200 sitting around (although the case is cracked after a drop) but I've held off on trying libreboot because it requires a ~$50 piece of hardware to flash it (a BeagleBone Black)
That's true. They don't officially support the Raspberry Pi because it needs proprietary drivers and thus breaks the "chain of trust" needed for flashing Libreboot.
It's a bit over-the-top paronoid to expect firmware modifying software in GPU drivers, but I understand their point.
To call the binary blobs on the Pi "GPU drivers" is an understatement. The VC4 is running the full ThreadX operating system. The Pi is closer to a VC4 board with a secondary ARM coprocessor tacked on than it is to an ARM board.
All the same, is your adversary really going to use this to attack your machine? They'd have to predict a number of things quite in advance, as well as sneak an attack into the blob.
> The Raspberry Pi boots from its GPU and only non-free software is currently available for the GPU, even starting the machine requires a large (2MB) blob of non-free, unsupportable software
The VC4 GPU actually is the primary chip; it boots the ThreadX operating system on the VC4 first, then ThreadX loads the user-configured system onto the ARM core. Whether you run headless or not, ThreadX is running on the VC4.
Could you direct me to a tutorial on that? I contacted the Libreboot devs before and they told me they wouldn't give any info out about using a different device
I don't have any hope for other hardware. The only hope that I have is that Intel will change their mind and remove it, or make it fully open source.
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.
AFAIK not even Google could get Intel to share the source code on their chips in order to make some of their Chromebooks. If Google can't do it, I doubt a handful of "GNU extremists" are going to change their minds.
Agreed. But it has to rewritten, that takes some time and costs money. It's another barrier preventing Intel to chanige their mind about it. But in the end it would be open source if Intel changed their mind.
I think someone has to leak everything, Snowden-style, although with all the increasing "security" that could be a bit difficult... nevertheless, if someone does decide to be a hero and do it, I fully support their efforts.
Unless this leak revealed that the NSA forced Intel and AMD to include ME in their chips to advance their mass spying efforts such a leak would be a crime. Snowden's case is different since he was revealing info that Americans (or their reps) have a right to know. The intelligence agencies are building a mass surveillance infrastructure that is prima facie not compatible with a free country and almost certainly a violation of the constitution. The constitution and amendments do not directly apply to Intel and they are free to do whatever they want and we are free to buy or not to buy as we see fit.
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.
IMHO, at this level binary compatibility isn't important. Linux could be easily ported to run on any ISA.
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?
I don't think it will ever be possible to prove that given piece of hardware contains no malware. Still, there is demand for transparency and product that comes with manufacturer's warranty that says "malware not included". People believe this could lead to some good results, such as better hardware and lower probability of bugged computer.
It's theoretically possible, provided you have a small trusted circuit. It's an active research area. The basic idea is to use multiple separate, untrusted chips and have them do multiparty computation, coordinated by the small trusted circuit.
With testing amplification, you can then set an upper bound on the probability that the chip will run a backdoor.
My personal requirements mandate "a cheap sturdy laptop". Do such things exist for non-X64 architectures? I'm not sure where I would even start to look.
There were a few chromebooks that ran on ARM chips. Not sure about sturdy, but they were definitely cheap. (And, you can enable developer mode and then use whatever flavor of Linux you like.)
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...)
Novena is great, but it certainly isn't cheap, isn't sturdy, and to be honest, unless you were lucky enough to snag a Senoko battery board, isn't a laptop. (I'm fortunate enough to own a few Novena boards).
> You're only locked in if your personal requirements mandate the smallest lithography process and the highest clock speed.
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.
Not easily, one issue is patents. Another issue however with x64 is for example SYSENTER vs SYSCALL. Windows for example has a whitelist of CPU vendors that it will use.
There have been rumors (for a while) that VIA is looking to seriously get back in the x64 game. So as far as I'm aware they have yet to attempt anything like Intel ME/AMD PSP.
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 is an Intel standard; they own the patents. Some of the patents have expired at this point but there's new ones which you would need in order to make a competing x86 processor.
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.
It's my understanding the only reason they cross-license today is both have big enough patent warchests as to place them in MAD. So it's probably quite unlikely Joe Startup could ever get a license.
x64 is copy righted only AMD, Intel, and VIA have the rights. There are also some patent protections.
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.
x86 hasn't been around long enough for a copyright to expire; the only feasible type of protections to expire would be patents. In the US, copyrights last for 120 years after creation of the work or 95 years after the initial publication, whichever is shorter. (Referenced from https://en.wikipedia.org/wiki/Copyright_law_of_the_United_St...)
Interesting that the ME region can be even partially overwritten and will still let the system boot, albeit with an error (guessing a checksum mismatch)...
The Management Engine, think of it as running at Ring -1. It can access hardware below the level of the processor. Injecting malware into it would be the holy grail for attackers, it would be impossible for anything running on the CPU to detect it and the malware would have access to all of the low level hardware. It can even intercept or create packets on the network interfaces.
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.
My next question is (and it's probably mentioned further in the thread or manual somewhere): how does the ME chipset route traffic to the Internet in the first place? Piggyback off the OS? Does this mean it's directly coupled with the networking devices on the system somehow? Presumably it will work with any OS....
but it still needs and IP address right? Does ME does its own DHCP/BOOTP configuration or does it rely on some other protocol specific to Intel NICs/Intel infrastructure?
The AMT component must be specifically configured with network information. It is usually kept on a different interface from that used by the OS for security reasons.
What are the odds that it was put there at their request, or partially specified by them? After all, the clipper chip never went anywhere, but neither did the desire.
"The ME code to start the platform is in (on-chip) ROM and a failed
signature check of the (compressed with AFAIK still unknown codebook)
ME code in flash just means that the ME considers the system broken
and allows it to run for a little while so that a human can repair it."
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?
I am fascinated by this - is there no where that is leading the charge to develop personal computing devices that are truly open? What cost level are we really talking here?
There are some places that are trying to do fully open source hardware, but because the majority of the public doesn't care (they just want their computer to work), nothing big has come out yet.
First you have to build a Fab that you trust. Then build an assembly line that you trust. Then make sure these don't have any humans in them, since humans are not trustworthy.
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...