Exploits: Intel CPU Backdoors, More Undocumented Instructions

grarpamp grarpamp at gmail.com
Thu Jul 15 05:29:52 PDT 2021


https://www.youtube.com/watch?v=_eSAF_qT_FY  God Mode
https://www.youtube.com/watch?v=LA_DrBwkiJA  Lern about puters and proggies
https://www.youtube.com/watch?v=KrksBdWcZgQ  Crunch Mode

At the beginning of 2020, we discovered the Red Unlock technique that
allows extracting microcode
(ucode) and targeting Intel Atom CPUs. Using the technique we were
able to research the internal
structure of the microcode and then x86 instructions implementation.
We found two undocumented
x86 instructions which are intendent to control the microarhitecture
for debug purposes. In this paper
we are going to introduce these instructions and explain the
conditions under which they can be used
on public-available platforms. We believe, this is a unique
opportunity for third-party researchers to
better understand the x86 architecture.

1    Introduction
The existence of undocumented mechanisms in the internals of modern
CPUs has always been a concern for information
security researchers and ordinary users. Assuming that such mechanisms
do exist, the main worry is that it might
be possible to bypass the implemented CPU protection mechanisms that
control access to memory and peripherals
containing personal user data. It is considered to be unacceptable for
a processor manufacturer or any other organization
to be able to get unauthorized access to data that the user regards as
confidential by bypassing documented, well-known
protection mechanisms and using methods that only the manufacturer
knows about (whether those methods are based
on the processor functionality or are intentionally designed for such
purposes, or have a legitimate purpose but also
allow bypassing protection due to certain architectural properties).
Such mechanisms include the following:
      1. Special CPU operating modes in which standard access control
rules do not work or work differently compared
         to what is described in the documentation (for Intel CPUs, it
is the Software Developer's Manual [1], which is
         intended for developers of applications running on Intel processors).
      2. Special CPU microarchitectural states in which certain access
control rules can be violated (for example, such
         states can be achieved by performing a specific instruction sequence).
       3. Undocumented CPU instructions that allow bypassing
protection mechanisms (for example, memory protec-
          tion) and grant special privileges to the calling code.
The existence of such undocumented capabilities in Intel processors
has always been a subject for debates and
speculations among information security specialists. For more than 40
years of the existence of the x86 architecture,
a number of significant studies have been conducted on this subject
[2],[3],[4]. Several undocumented features have
been discovered (e.g. undocumented instructions described in [3]),
including one that allows bypassing implemented
protection [5], but this was found for very old Intel processors
(80286 and 80386). Thereafter no apparent undocumented
methods to gain unauthorized access have been found in x86 processors
manufactured directly by Intel. This is leaving
aside multiple recently discovered transient execution vulnerabilities
and data leaks caused by side-channel attacks
(such as Meltdown and Spectre), which are by no means intentional and
are generally admitted to be design errors due to
prioritizing higher performance over security. However, our research
team managed to find at least two undocumented
x86 instructions and a special processor debugging mode called Red
Unlock (detailed information about the mode
is given in a separate section of this paper) in actual Intel CPUs.
Combined, these capabilities make it possible to
completely bypass the existing memory protection and equipment control
mechanisms. Moreover, the discovered
instructions provide access to the processor at the microcode level
and thus allow overriding the semantics of the main
x86 instructions (that is, a set of the most important instructions in
terms of security). This is by far more dangerous
than, for example, violating memory protection (x86 privilege levels,
or so-called protection rings) because it enables
malware to be implemented at a level where it is impossible to detect
it with modern protection tools and defend the
system against it.
We should clarify in advance that, in our opinion, these instructions
were initially introduced to facilitate the debugging
of processors at the microarchitecture (hardware implementation) level
exclusively by Intel engineers. However, due
to a total absence of available documentation on these features
(including description of all the possible ways to use
them), we believe that these instructions are rather dangerous and
that the Red Unlock service mode intended for
processor debugging must not be implemented in production parts
distributed by sales outlets and utilized by end users
in their everyday tasks. In our view, Intel was obliged to at least
inform users about the existence of these instructions
and special CPU debugging mode so that users could be aware of the
risks associated with the company's products.
Moreover, on some platforms it is possible to enable this CPU
debugging mode using hardware means that can be
accessed by the Intel Converged Security and Management Engine (Intel
CSME) [6]. A number of critical arbitrary
code execution vulnerabilities [7], [8] recently discovered in the
Intel CSME subsystem can be exploited to switch the
CPU to the debugging mode, as was demonstrated by our company's
experts [9]. This makes the Red Unlock mode
available for virtually anyone who wishes to use it (rather than to
Intel engineers only, as it was originally intended).


7 Conclusion
As described in this paper, we discovered two undocumented x86
instructions that allow reading and writing microarchi-
tectural data and called them udbgrd and udbgwr, respectively. One of
the commands supported for the instructions is
the CRBUS read/write command, which can be used to modify microcode in
MSROM via Patch RAM and match/patch
registers. We can prove the existence of these undocumented
instructions in Atom Goldmont and Atom Goldmont
Plus processors - see our PoC published together with the paper [14].
We found that the instructions must be activated
through MSR 0x1e6 and that the processor executes them only after
performing the DFX unlock procedure called Red
Unlock. In our opinion, the instructions are intended for CPU
microarchitecture debugging by Intel engineers; however,
the existence of such instructions poses a security threat since there
is publicly available PoC code [9] that can activate
the Red Unlock mode on one of the modern Intel platforms. Moreover, we
demonstrated that speculative execution of
microoperations (rather than macroinstructions that they implement) is
possible for udbgrd/udbgwr, which needs to be
thoroughly examined with regard to all present-day Intel processors.
For this purpose, we created a special tool [22] that,
when run on a processor, checks whether the udbgrd and udbgwr
instructions can be executed on it and, if not, checks
whether the processor allows speculative writing and reading of
microarchitectural data when calling the instructions.
This tool executes the udbgwr instruction to write a specific URAM
address (Time Stamp Counter (TSC) multiplier
used by the rdtsc x86 instruction), which is known for Big Cores as
well as for Atom Goldmont, and then attempts
to read the written data using architectural mechanisms available in
User Mode. The tool also tries to speculatively
read the TSC multiplier in URAM with the udbgrd instruction by using
CPU cache as a mechanism to retrieve the read
data. On top of that, we were the first to publicly provide a list of
all (as far as we can tell) possible ways to activate
the Red Unlock mode for CPU debugging and to demonstrate that some of
them are rather dangerous (for example,
software-based unlocking via Intel CSME and PUNIT firmware and
processor-specific OTP configuration).

More information about the cypherpunks mailing list