For we wrestle not against flesh and blood, but against principalities, against powers, against the rulers of the darkness of this world, against spiritual wickedness in high places. — Ephesians 6:12

Original art design - The Fellowship of Libre firmware: Hunting the Shadow

最初の章：預言者の到来

Since the birth of the technology deity, the free software/firmware/hardware community has faced numerous adversaries, and Intel ME (Management Engine) stands as one of the most clandestine enemies. Intel ME is a self-contained and complete software-hardware system within the x86 platform chipset (PCH). Ever since its integration into the x86 chipset in 2006 (AMT 2.0), it has been subjected to intense scrutiny. At the 2009 Blackhat conference, Rafal Wojtczuk and Alexander Tereshkin from ITL (Invisible Things Lab) publicly showcased the vulnerabilities in AMT/ME that could be exploited by injecting specific DMA memory. This marked the first revelation of the potential for a Ring -3 rootkit. It was a time when Intel heavily promoted TPM/TXT. ITL provided the security community with crucial information from a technical assessment perspective. In the realm of security research below Ring 0, ITL was akin to a prophet. Over the years, their continuous discoveries have served as significant references for the subsequent free firmware community.

Note: To better illustrate the hierarchy of privilege levels, ITL referred to the operating system kernel as Ring 0, the hypervisor as Ring -1 (the persistence of the VM layer directly corresponds to Ring 0), UEFI/SMM as Ring -2 (in typical scenarios, the standard protections of Ring 0, such as page table isolation, and Ring -1, such as shadow page tables, EPT, chipset IOMMU/Vt-d, are almost ineffective against Ring -2), and Intel ME is considered as Ring -3.

Birth of the Shadow Dagger

Since 2009, researchers have diligently scrutinized specific code modules of Intel ME, with a particular focus on AMT, from various technical perspectives. Their efforts have led to the discovery of vulnerabilities and potential security risks. Surprisingly, the industry did not pay significant attention to these findings for a prolonged period. Only a handful of hackers within the open firmware community were actively engaged in this area. Unfortunately, detailed technical assessments and comprehensive defense strategies were still missing pieces. However, in 2014, Patrick Stewin’s thesis paper shed light on a rootkit named DAGGER, which functioned as a peripheral device for keylogging. To facilitate testing, DAGGER capitalized on a vulnerability present in the 2009 ITL. Notably, DAGGER played a pivotal role as the cornerstone of firmware security in the “ Hardening the COREs” scheme developed by h4rdenedzer0.

Hunting the Shadow

Until 2016, the mainstream approach in the free/open firmware community was to completely remove all ME code modules and data. However, extensive research and testing revealed a significant challenge: while ME could be successfully cleared from Core 2 era chipsets, removing ME code modules on Nehalem/Westmere and newer chipsets led to the machine shutting down after 30 minutes (although there were a few individuals who tolerated the inconvenience of restarting their computers every half an hour -_-). This dilemma posed a longstanding issue within the community.

In September 2016, Trammell Hudson found that removing the first 4KB of the ME region did not trigger a shutdown. Shortly thereafter, another revelation emerged: by retaining only the FTPR partition and removing all other code modules, the x230 could be prevented from shutting down. Building on this progress, Nicola Corna and Federico Amedeo Izzo developed a tool in November 2016. This tool effectively deleted most of the code modules and created an FPT with an FPTR partition. It served as the precursor to what we now know as me_cleaner. Throughout the testing phase, h4rdenedzer0 actively participated in almost every round, while one of our members attended seminars in Russia during that month. Their investigations uncovered a grave concern: certain applications hosted by Intel ME posed a significant threat to the free firmware community and existing production environments in enterprises. This realization spurred h4rdenedzer0 to mobilize and engage more security professionals and members of the free software community in the battle against Intel ME.

Having successfully executed Nicola and Federico’s tool on multiple x86 devices, h4rdenedzer0 reached out to the authors and proposed uploading the code to GitHub. They also encouraged greater participation from individuals and companies to join the community to testing and reverse engineering. Subsequently, the tool was officially named me_cleaner. During this period, h4rdenedzer0 conducted extensive testing on various models and openly shared the results of their investigations. To foster broader community involvement, standardized operational documentation was released, attracting attention and media coverage from the IT industry within the same month. A month later, at the 33C3, Europe’s largest hacker conference held in Hamburg in December 2016, the coreboot workshop organized by the free/open firmware community provided a platform for hundreds of participants to successfully test the models they brought. This series of events served as the catalyst for more community activities on Intel ME that unfolded in 2017.

Total war

The increasing interest from the free software community has led to a growing focus on Intel ME. This has also captured the attention of highly skilled Russian security researchers specializing in reverse engineering. In March 2017, Dmitry Sklyarov publicly disclosed some details about his reverse engineering efforts on Intel ME. This disclosure provided us with a deeper understanding of the structure of the latest version of Intel ME. Prior to Dmitry’s findings, we had already studied one of the prominent features of the x86 processor in Skylake (2015), which is SGX. SGX relies on various ME features for implementation. Aside from addressing ARC*/Sparc performance issues, the utilization of x86 CPUs in MEv11 is believed to be a significant factor. Dmitry’s reverse engineering revealed that the operating system running on MEv11 is not ThreadX, as used in the previous ARC* architecture, but rather a customized system based on the MINIX system. During that time, me_cleaner had not extensively tested Skylake and newer processors. Further adjustments to code module handling were necessary for me_cleaner. To support this effort, a member of h4rdenedzer0 generously donated 2,600 euros to the maintainer of me_cleaner for the purchase of testing equipment. After several months of bug fixing and rigorous testing, me_cleaner successfully accomplished the task of cleaning MEv11 and MEv12 (Skylake/Kabylake/Cannonlake). On platforms above Skylake, most ME implementations now retain only the RBE, KERNEL, SYSLIB, and BUP modules.

In August 2017, Mark Ermolov and Maxim Goryachy, through reverse engineering, discovered a hidden killswitch within ME that the NSA used for defensive purposes. They revealed that it is indeed possible to completely disable ME. This killswitch, known as HAP (with an equivalent AltMeDisable on ARC-based ME and older versions like ICH_MeDisable, MCH_MeDisable, and MCH_AltMeDisable used for Core 2 chipsets without ME), is concealed within the PCHSTRP0 field of the descriptor. The location of equivalent bits may vary in older versions (refer to the source code of me_cleaner for specific details). Notably, this bit is not officially documented. Interestingly, HAP stands for High Assurance Platform, which is an NSA initiative to construct the next-generation security defense system. Considering that NSA machines have the HAP bit enabled (ME is disabled after completing necessary initialization work during BringUP), while the majority of x86 machines worldwide run ME by default, it implies that ME poses a substantial risk to core infrastructure as a potential backdoor or “backdoor accomplice.” For businesses with high-security requirements, merely transferring core operations to an operating system running on an external CPU does not address the fundamental issue of the insecurity of the main CPU’s operating system kernel. Instead, it introduces new risks and the challenge of dealing with non-auditable systems. Although the Linux kernel is not immune to vulnerabilities, it remains open source and benefits from open audits. In contrast, the software and hardware associated with ME are closed source for most individuals, leaving the issue of auditability unresolved on x86 platforms.

In November 2017, Google engineers made a significant announcement at the European coreboot conference in Germany. They expressed their intention to eliminate Intel ME and non-open-source UEFI firmware implementations from critical business machines. This decision was driven by Google’s concerns regarding the risk assessment results associated with Intel ME.

In December 2017, Russian security researchers delivered a notable demonstration at Blackhat EU. They showcased the “inaction” of Intel ME during the BringUP (BUP) phase, which inadvertently enabled a specific attack chain. Presently, there is no conclusive evidence to support the notion that Intel intentionally allowed this vulnerability. Even with HAP enabled, this vulnerability remains impervious to defense. Mitigation strategies must be implemented at the kernel and firmware levels. For servers, it is possible to combine this vulnerability with SA-00075 (AMT vulnerability) to remotely target machines manufactured between 2015 and 2017. This vulnerability signifies a new era since 2009 when pioneers of firmware security at ITL set the stage for a paradigm shift. It marks the advent of a cost-effective era for both attack and defense at the Ring-3 level.

In June 2018, Russian security researchers made further discoveries during their analysis of the IDLM code module, as detailed in the IDLM code module analysis document. Notably, Intel accorded significant importance to security in certain ME code modules but exhibited negligence toward high-risk modules like IDLM. Russian security researchers speculate that this negligence might be intentional on Intel’s part. Numerous ME-related code modules demonstrate similar behavior.

Solution?

In high-security environments, it is advisable to avoid using the ME system and any applications that run on it. However, in industries such as finance and telecommunications, a complete short-term replacement of x86 is highly challenging. Nevertheless, businesses can assess the importance and priority of their operations to determine whether the ME module should be removed.

Taking a long-term perspective, there are two key considerations. Firstly, the lack of audibility in firmware, including microcode and ME, poses a significant barrier within the x86 platform. It is unlikely that Intel will address this obstacle comprehensively. On the other hand, the entire chip industry is embracing a new era known as “3.0” with the emergence of open instruction set CPU architectures like RISC-V (updated in 2023: RISC-V can’t resolve the transparency issues due to several reasons). This shift will gradually resolve the issue of audibility in chips and firmware. Achieving true hardware and firmware freedom necessitates both hardware and firmware being open to auditing.

Epilogue

The Intel ME has sparked continuous interest within the community, leading to inquiries about diverse aspects such as risk assessment, backdoor stories, design and implementation, reverse engineering progress, and more. In this article, h4rdenedzer0 offers some insights from their perspective. It is important to acknowledge the substantial support received from countless hackers, security researchers, and volunteers in the free firmware community during the hunt for answers. However, due to various constraints, it is not feasible to list all their contributions here.

ME info

2006 - 2014:

* Notebooks and desktops employed the standard ME implementation, running on Arc* processors with the ThreadX operating system.
* Starting from the Nehalem/Westmere series, ME could not be completely removed.
* Embedded devices utilized TXE, running on Sparc processors, with an unknown RTOS as the operating system.
* Servers employed SPS, running on Arc* processors with the ThreadX operating system.

2015 - Present:

* Customized OS based on Minix 3, running on x86 processors.