It is actually a scandal that the world depends on chips and operating systems – that are designed to do mass-surveillance – it seems – in order to build up a world-wide-dictatorship that no-one can escape… by information and money.

 

src: http://www.thg.ru/mainboard/intel_vpro/print.html

countermeassures: https://dwaves.de/2018/06/18/how-to-install-flash-libreboot-coreboot-on-lenovo-x60s-tutorial-from-2018/ or support free hardware crowdsupply projects.

short story:

„The Intel Management Engine (Intel ME) refers to the hardware features that operate at the baseboard level, below the operating system. By enabling interaction with low-level hardware, Intel gives administrators the ability to perform tasks that previously required someone to be physically present at the desktop.“ (src: http://www.tomshardware.com/reviews/vpro-amt-management-kvm,3003-6.html)

https://www.blackhat.com/eu-17/briefings/schedule/#how-to-hack-a-turned-off-computer-or-running-unsigned-code-in-intel-management-engine-8668

long story:

Intel Management Engine (ME)

Introduced in June 2006 in Intel’s 965 Express Chipset Family of (Graphics and) Memory Controller Hubs, or (G)MCHs, and the ICH8 I/O Controller Family, the Intel Management Engine (ME) is a separate computing environment physically located in the (G)MCH chip. In Q3 2009, the first generation of Intel Core i3/i5/i7 (Nehalem) CPUs and the 5 Series Chipset family of Platform Controller Hubs, or PCHs, brought a more tightly integrated ME (now at version 6.0) inside the PCH chip, which itself replaced the ICH. Thus, the ME is present on all Intel desktop, mobile (laptop), and server systems since mid 2006.

The ME consists of an ARC processor core (replaced with other processor cores in later generations of the ME), code and data caches, a timer, and a secure internal bus to which additional devices are connected, including a cryptography engine, internal ROM and RAM, memory controllers, and a direct memory access (DMA) engine to access the host operating system’s memory as well as to reserve a region of protected external memory to supplement the ME’s limited internal RAM. The ME also has network access with its own MAC address through an Intel Gigabit Ethernet Controller. Its boot program, stored on the internal ROM, loads a firmware “manifest” from the PC’s SPI flash chip. This manifest is signed with a strong cryptographic key, which differs between versions of the ME firmware. If the manifest isn’t signed by a specific Intel key, the boot ROM won’t load and execute the firmware and the ME processor core will be halted.

The ME firmware is compressed and consists of modules that are listed in the manifest along with secure cryptographic hashes of their contents. One module is the operating system kernel, which is based on a proprietary real-time operating system (RTOS) kernel called “ThreadX”. The developer, Express Logic, sells licenses and source code for ThreadX. Customers such as Intel are forbidden from disclosing or sublicensing the ThreadX source code. Another module is the Dynamic Application Loader (DAL), which consists of a Java virtual machine and set of preinstalled Java classes for cryptography, secure storage, etc. The DAL module can load and execute additional ME modules from the PC’s HDD or SSD. The ME firmware also includes a number of native application modules within its flash memory space, including Intel Active Management Technology (AMT), an implementation of a Trusted Platform Module (TPM), Intel Boot Guard, and audio and video DRM systems.

The Active Management Technology (AMT) application, part of the Intel “vPro” brand, is a Web server and application code that enables remote users to power on, power off, view information about, and otherwise manage the PC. It can be used remotely even while the PC is powered off (via Wake-on-Lan). Traffic is encrypted using SSL/TLS libraries, but recall that all of the major SSL/TLS implementations have had highly publicized vulnerabilities. The AMT application itself has known vulnerabilities, which have been exploited to develop rootkits and keyloggers and covertly gain encrypted access to the management features of a PC. Remember that the ME has full access to the PC’s RAM. This means that an attacker exploiting any of these vulnerabilities may gain access to everything on the PC as it runs: all open files, all running applications, all keys pressed, and more.

Intel Boot Guard is an ME application introduced in Q2 2013 with ME firmware version 9.0 on 4th Generation Intel Core i3/i5/i7 (Haswell) CPUs. It allows a PC OEM to generate an asymmetric cryptographic keypair, install the public key in the CPU, and prevent the CPU from executing boot firmware that isn’t signed with their private key. This means that coreboot and libreboot are impossible to port to such PCs, without the OEM’s private signing key. Note that systems assembled from separately purchased mainboard and CPU parts are unaffected, since the vendor of the mainboard (on which the boot firmware is stored) can’t possibly affect the public key stored on the CPU.

ME firmware versions 4.0 and later (Intel 4 Series and later chipsets) include an ME application for audio and video DRM called “Protected Audio Video Path” (PAVP). The ME receives from the host operating system an encrypted media stream and encrypted key, decrypts the key, and sends the encrypted media decrypted key to the GPU, which then decrypts the media. PAVP is also used by another ME application to draw an authentication PIN pad directly onto the screen. In this usage, the PAVP application directly controls the graphics that appear on the PC’s screen in a way that the host OS cannot detect. ME firmware version 7.0 on PCHs with 2nd Generation Intel Core i3/i5/i7 (Sandy Bridge) CPUs replaces PAVP with a similar DRM application called “Intel Insider”. Like the AMT application, these DRM applications, which in themselves are defective by design, demonstrate the omnipotent capabilities of the ME: this hardware and its proprietary firmware can access and control everything that is in RAM and even everything that is shown on the screen.

The Intel Management Engine with its proprietary firmware has complete access to and control over the PC: it can power on or shut down the PC, read all open files, examine all running applications, track all keys pressed and mouse movements, and even capture or display images on the screen. And it has a network interface that is demonstrably insecure, which can allow an attacker on the network to inject rootkits that completely compromise the PC and can report to the attacker all activities performed on the PC. It is a threat to freedom, security, and privacy that can’t be ignored.

Before version 6.0 (that is, on systems from 2008/2009 and earlier), the ME can be disabled by setting a couple of values in the SPI flash memory. The ME firmware can then be removed entirely from the flash memory space. libreboot does this on the Intel 4 Series systems that it supports, such as the Libreboot X200 and Libreboot T400. ME firmware versions 6.0 and later, which are found on all systems with an Intel Core i3/i5/i7 CPU and a PCH, include “ME Ignition” firmware that performs some hardware initialization and power management. If the ME’s boot ROM does not find in the SPI flash memory an ME firmware manifest with a valid Intel signature, the whole PC will shut down after 30 minutes.

Due to the signature verification, developing free replacement firmware for the ME is basically impossible. The only entity capable of replacing the ME firmware is Intel. As previously stated, the ME firmware includes proprietary code licensed from third parties, so Intel couldn’t release the source code even if they wanted to. And even if they developed completely new ME firmware without third-party proprietary code and released its source code, the ME’s boot ROM would reject any modified firmware that isn’t signed by Intel. Thus, the ME firmware is both hopelessly proprietary and “tivoized”.

In summary, the Intel Management Engine and its applications are a backdoor with total access to and control over the rest of the PC. The ME is a threat to freedom, security, and privacy, and the libreboot project strongly recommends avoiding it entirely. Since recent versions of it can’t be removed, this means avoiding all recent generations of Intel hardware.

More information about the Management Engine can be found on various Web sites, including me.bios.io, unhuffme, coreboot wiki, and Wikipedia. The book Platform Embedded Security Technology Revealed describes in great detail the ME’s hardware architecture and firmware application modules.

If you’re stuck with the ME (non-libreboot system), you might find this interesting: http://hardenedlinux.org/firmware/2016/11/17/neutralize_ME_firmware_on_sandybridge_and_ivybridge.html

Also see (effort to disable the ME): https://www.coreboot.org/pipermail/coreboot/2016-November/082331.html – look at the whole thread

Firmware Support Package (FSP)

On all recent Intel systems, coreboot support has revolved around integrating a blob (for each system) called the FSP (firmware support package), which handles all of the hardware initialization, including memory and CPU initialization. Reverse engineering and replacing this blob is almost impossible, due to how complex it is. Even for the most skilled developer, it would take years to replace. Intel distributes this blob to firmware developers, without source.

Since the FSP is responsible for the early hardware initialization, that means it also handles SMM (System Management Mode). This is a special mode that operates below the operating system level. It’s possible that rootkits could be implemented there, which could perform a number of attacks on the user (the list is endless). Any Intel system that has the proprietary FSP blob cannot be trusted at all. In fact, several SMM rootkits have been demonstrated in the wild (use a search engine to find them).

CPU microcode updates

All modern x86 CPUs (from Intel and AMD) use what is called microcode. CPUs are extremely complex, and difficult to get right, so the circuitry is designed in a very generic way, where only basic instructions are handled in hardware. Most of the instruction set is implemented using microcode, which is low-level software running inside the CPU that can specify how the circuitry is to be used, for each instruction. The built-in microcode is part of the hardware, and read-only. Both the circuitry and the microcode can have bugs, which could cause reliability issues.

Microcode updates are proprietary blobs, uploaded to the CPU at boot time, which patches the built-in microcode and disables buggy parts of the CPU to improve reliability. In the past, these updates were handled by the operating system kernel, but on all recent systems it is the boot firmware that must perform this task. Coreboot does distribute microcode updates for Intel and AMD CPUs, but libreboot cannot, because the whole point of libreboot is to be 100% free software.

On some older Intel CPUs, it is possible to exclude the microcode updates and not have any reliability issues in practise. All current libreboot systems work without microcode updates (otherwise, they wouldn’t be supported in libreboot). However, all modern Intel CPUs require the microcode updates, otherwise the system will not boot at all, or it will be extremely unstable (memory corruption, for example).

Intel CPU microcode updates are signed, which means that you could not even run a modified version, even if you had the source code. If you try to upload your own modified updates, the CPU will reject them.

The microcode updates alter the way instructions behave on the CPU. That means they affect the way the CPU works, in a very fundamental way. That makes it software. The updates are proprietary, and are software, so we exclude them from libreboot. The microcode built into the CPU already is not so much of an issue, since we can’t change it anyway (it’s read-only).

Intel is uncooperative

For years, coreboot has been struggling against Intel. Intel has been shown to be extremely uncooperative in general. Many coreboot developers, and companies, have tried to get Intel to cooperate; namely, releasing source code for the firmware components. Even Google, which sells millions of chromebooks (coreboot preinstalled) have been unable to persuade them.

Even when Intel does cooperate, they still don’t provide source code. They might provide limited information (datasheets) under strict corporate NDA (non-disclosure agreement), but even that is not guaranteed. Even ODMs and IBVs can’t get source code from Intel, in most cases (they will just integrate the blobs that Intel provides).

Recent Intel graphics chipsets also require firmware blobs.

Intel is only going to get worse when it comes to user freedom. Libreboot has no support recent Intel platforms, precisely because of the problems described above. The only way to solve this is to get Intel to change their policies and to be more friendly to the free software community. Reverse engineering won’t solve anything long-term, unfortunately, but we need to keep doing it anyway. Moving forward, Intel hardware is a non-option unless a radical change happens within Intel.

Basically, all Intel hardware from year 2010 and beyond will never be supported by libreboot. The libreboot project is actively ignoring all modern Intel hardware at this point, and focusing on alternative platforms.

src: https://libreboot.org/faq.html#intel

But why do they not give you the documentation and the manual – to use and utilize this supreme cool feature they build into your computer?

Because you are not meant to use it. I have NEVER seen an Administrator using it.

So please consider support and buying and testing the first kickstarting-Open-Hardware-projects in doing.

Intel’s ME is deeply integrated in the chipset, or SoC.

In computers with Intel processors, the so-called Management Engine (ME) is using undocumented functions;

to remove the encrypted Firmware, there are now Tools for brave hobbyists.

The Italian programmer Nicola Corna has the Tool me_cleaner developed a proprietary and encrypted (see Update 2) Firmware of the Intel Management Engine (ME) BIOS Images removed.

It is, ultimately, a Python script, which some of the so-called Firmware-partitions of the modular (UEFI)BIOS clears simply or overrides. Then fit me_cleaner the Firmware Partition Table (FPT) of the BIOS Images to the System BIOS Code at all to load and to re-boot.

The aim of the campaign is to prevent the execution of the ME, or to block at least their communication and interfaces, for example, by the network Stack is removed from the BIOS Code.

Indeed, there are significant concerns about the undocumented functionality of the ME, which is, in principle, be able to all of the data of an ongoing computer access.

Function circumcision

Nicola Corna expressly points out that the me_cleaner can lead to total failure of a treated computer and many unknown effects on the PC-operation possible.

So, for example, on the Hand, the ME Firmware without a network Stack can provide remote maintenance via Ethernet.

[Update 2:] it was here that the Removal of the ME-network Firmware via Ethernet via PXE blocked, but this Boot Code has nothing to do with the ME Firmware to do.

me_cleaner away, but probably also the Basis of the Protected Audio/Video Path (PAVP), which is likely to undermine on Windows computers DRM-systems, the commercial Streaming services such as Netflix or Amazon Prime Video.

Finally, Trusted Platform Modules according to the fTPM 2.0 should not work – Microsoft BitLocker may be in turn.

However, for people running Windows systems with proprietary Code, the shutdown of the ME is in any case little sense. (in terms of privacy and security)

The BIOS Image with the undocumented ME-Code"Blob" is Far from the only proprietary Firmware in PCs.
The BIOS Image with the undocumented ME-Code“Blob“ is Far from the only proprietary Firmware in PCs. Zoom in
Since the full functionality of the ME undocumented, but also has an impact on power consumption and stability of the computer possible – and also on how feedback brave hobbyists on the GITHub page of the project me_cleaner documents.

External Flash

Use of the me_cleaner is some prior knowledge and special Hardware required: With an external programming adapter for SPI(NOR)Flash Chips, you have to at first, the BIOS Code or the BIOS Image from the memory chip (Notebook)motherboard extract. Then, to edit a copy of the BIOS Image on another System with the me_cleaner to write it again with the programming adapter in the Chip.

[Update:] Of course, you can edit the BIOS-Image is also of a suitable BIOS Update file to extract for each Computer, with me_cleaner and then with a Flash Tool under DOS, Linux, or Windows in the Chip to write or in many BIOS Setups the built-in Flash Tools. However, many manufacturer-specific Flash-Tool checks the BIOS Image before Writing, universal Tools work on every System.And if the computer with the me_cleaner edited the BIOS-no more boot Image, you need a device with an external programmer.

Questionable Success

Quite frankly, Nicola Corna explained that there is of course no proof of this, that can give me_cleaner binds the function to the ME. He developed me_cleaner on the Basis of new findings of inventors such as Trammell Hudson and Igor Skochinsky more and also hopes for feedback from volunteer testers. On systems with Intel Boot Guard works me_cleaner not, because the execution of unsigned Firmware to prevent.

Intel Management Engine (ME)
The ME consists of a micro controller, which is part of the chipset or CPU SoCs, as well as the compressed and encrypted ME Firmware that’s in the BIOS Code Image. Zoom in
Image: Intel
Ultimately, it is up to Intel, finally, the function and the Code of ME to disclose, in order to strengthen the cracked confidence in their own processors and platforms.

[Update 3:] The ME Firmware is signed and compressed, but not in the real sense in an encrypted form, For parts of the code uses Intel conventional LZMA compression, a proprietary (Huffman)coding, in the corresponding dictionary, but in the chip-set is stored. In April 2015 there is a decompressor for ME Firmware up to the Haswell Generation (ME versions 6 to 10). With Skylake (ME Version 11) has Intel switched for ME to a different micro controller than the previously used ARC-core.

Related Links:

auto-translated by: https://translate.yandex.com/translate

admin