Knowledge about CPU hardware

Question

Recently, I have taken the computer organization course that explains in the logic gate level how a CPU works and etc...

Up until now I have been treating the CPU as a black box that runs assembly instructions, even when I was learning in my free time about cracking, and doing exploits, and reverse engineering in general.

But that got me wondering, in the security field, how much research is being done using or combining CPU bugs, like software bugs, and using it to run code remotely or do other stuff.

Do reverse engineers, who try to find computer exploits, gain an advantage if they know the internal implementation of the CPU? Down to the logic gate level of course, not just the high level components.

Answer 1

To extend the answer of perror:

Perhaps you should take a look into a recently published whitepaper named Breaking the x86 ISA, by Christopher Domas. It was published on blackhat17 and describes an approach for digging into x86 chips and extracting hidden machine instructions.

Title:

Breaking the x86 ISA

Abstract:

A processor is not a trusted black box for running code; on the contrary, modern x86 chips are packed full of secret instructions and hardware bugs. In this paper, we demonstrate how page fault analysis and some creative processor fuzzing can be used to exhaustively search the x86 instruction set and uncover the secrets buried in a chipset. The approach has revealed critical x86 hardware glitches, previously unknown machine instructions, ubiquitous software bugs, and flaws in enterprise hypervisors.

Author: Christopher Domas

https://www.blackhat.com/docs/us-17/thursday/us-17-Domas-Breaking-The-x86-Instruction-Set-wp.pdf

Related Resources:

• https://github.com/xoreaxeaxeax/sandsifter

Somehow related microcode-internals from academia:

Title:

Reverse Engineering x86 Processor Microcode

Abstract: Microcode is an abstraction layer on top of the physical components of a CPU and present in most generalpurpose CPUs today. In addition to facilitate complex and vast instruction sets, it also provides an update mechanism that allows CPUs to be patched in-place without requiring any special hardware. While it is well-known that CPUs are regularly updated with this mechanism, very little is known about its inner workings given that microcode and the update mechanism are proprietary and have not been throughly analyzed yet. In this paper, we reverse engineer the microcode semantics and inner workings of its update mechanism of conventional COTS CPUs on the example of AMD’s K8 and K10 microarchitectures. Furthermore, we demonstrate how to develop custom microcode updates. We describe the microcode semantics and additionally present a set of microprograms that demonstrate the possibilities offered by this technology. To this end, our microprograms range from CPU-assisted instrumentation to microcoded Trojans that can even be reached from within a web browser and enable remote code execution and cryptographic implementation attacks.

Author: Philipp Koppe, Benjamin Kollenda, Marc Fyrbiak, Christian Kison, Robert Gawlik, Christof Paar, and Thorsten Holz

http://syssec.rub.de/media/emma/veroeffentlichungen/2017/08/16/usenix17-microcode.pdf

Related Work/Reads:

• http://inertiawar.com/microcode/

• https://argp.github.io/2017/09/14/re-x86-microcode/

EDIT: I added the reference mentioned by Dan.

Title:

Page Fault Liberation Army or Gained in Translation: a history of creative x86 virtual memory uses

Abstract:

x86 processors contain a surprising amount of built-in memory translation logic, which is driven by various data tables with intricate entry formats, and can produce various kinds of traps and other interesting computational effects. These features are mostly relics of earlier, more civilized times, when Jedi Knights tried to protect the Old Republic OSes with segmentation, supervisor bits, and hardware task support, but were defeated by processor de-optimizations and performance concerns and left unused by both Windows and UNIX systems – and explored only by hackers. For the rest of the world, an x86 PC was a "von Neumann architecture" with most of its strangeness unused.

Author: Julian Bangert and Sergey Bratus

https://media.ccc.de/v/29c3-5265-en-page_fault_liberation_army_h264

EDIT: I added the recently published spectre or meltdown attack, which exploits critical vulnerabilities in modern processors.

Title:

Meltdown and Spectre: Bugs in modern computers leak passwords and sensitive data

TLDR:

Meltdown and Spectre exploit critical vulnerabilities in modern processors. These hardware bugs allow programs to steal data which is currently processed on the computer. While programs are typically not permitted to read data from other programs, a malicious program can exploit Meltdown and Spectre to get hold of secrets stored in the memory of other running programs. This might include your passwords stored in a password manager or browser, your personal photos, emails, instant messages and even business-critical documents.

Paper:

https://meltdownattack.com/meltdown.pdf

https://spectreattack.com/spectre.pdf

Related Resources:

• https://googleprojectzero.blogspot.de/2018/01/reading-privileged-memory-with-side.html?m=1

• http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-the-linux-page-table

• https://lkml.org/lkml/2017/12/27/2

• https://gruss.cc/files/kaiser.pdf

• https://lwn.net/Articles/741878/

• https://lwn.net/Articles/738975/

Answer 2

In fact, the CPU are much more checked and verified than programs. It is very unlikely to find a (significant) bug in a CPU. Even though it happens from time to time.

Therefore, it is much more interesting to look at software bugs (because they are more likely) than hardware bugs.

Yet, you have a few occurrences of hardware bugs that led to disclosure of some "secrets". The most famous one being probably the one from the Bell company (the 2600Hz bug).

Basically, this bug was coming from the fact that they were two types of signals transmitted between the phone booth and the telecommunication central. The command signals and the voice signals:

• Command signals: They were used to send commands such as the destination of the phone call (phone number), the start/end of the communication, the amount of coins payed, and so on.

• Voice signals: They were used to encode the audio signal of the phone communication.

All these signals were encoded into an electrical signals and sent from the phone booth to the central. The problem was coming from the fact that the encoding module from the voice signals was not strictly bounded to usual human voice frequencies. One could produce an unusual sound in the phone and get an encoding that would be understood as a command signal by the central.

In fact, one hacker did realize that if you produced a sound of 2600Hz, the audio encoding of this signal was corresponding to a command signal of a long-distance call (it was as if you inserted a coin of 25 cents in the phone booth). And, by an extraordinary coincidence, at this time a brand of cereals (for kids' breakfast), called "Cap'n Crunch", was offering to his customers a whistle that was producing a sound of this exact same frequency.

At this time, these cereal boxes became very popular and the phone company did loose a bit of money. :-)

Answer 3

Modern microprocessors are quite complex, but probably can be represented in fewer lines of code than an OS plus libs, etc. (Although one would be coded in Verilog and the other in C.) Nonetheless, the complexity is so great that having source code wouldn't be of much benefit.

If we focus on instruction execution (vs peripheral functions like memory management), functionality is quite well defined, and therefore easy to verify. Moreover, the cost of a mistake is quite high--you can't simply push out a patch like you can in software. Therefore, designs are simulated for days before being taped out, and there are even formal methods to prove that every part of the chip has been exercised.

However, the amount of state held by a CPU is astronomical. A bug where the CPU jumped to the wrong instruction all the time would be quickly found. The reality is that there could be a rare sequence of events--perhaps not even easily reproducible given the stochastic nature of out-of-order processors--that leads to misbehavior. Such bugs would also be hard to exploit.

There are indeed bugs found after tape out. Most processors have an errata sheet, and few designs go to production on A0 (one full tape out, no metal fixes) silicon. But, I mostly see bugs or design gaps in peripheral functions. For an example list of bugs, search for something like "Skylake errata."

Answer 4

As a very specific example, I'm sure you could take the recently acknowledged SKL150 erratum and build an exploit on top of it that could tunnel through verification systems, JIT-compiled langauges, etc, since it breaks the basic assumption that the processor behaves as designed.

The "symptom" of SKL150 as reported was crashing, but that's only because the affected value was a pointer which became invalid, but you could equally use all the the regular techniques to exploit it instead. Of course, this is probably at the 9 out of 10 difficulty level.