Security

Everything you want to know about x86 microcode, but might have been afraid to ask

An introduction into reverse-engineering x86 microcode and writing it yourself
Microcode is an abstraction layer on top of the physical components of a CPU and present in most general-purpose CPUs today. While it is well-known that CPUs feature a microcode update mechanism, very little is known about its inner workings given that microcode and the update mechanism itself are proprietary and have not been throughly analyzed yet. We close this gap by both analyzing microcode and writing our own programs for it. This talk will give an insight into our results and how we achieved them, including live demos of what we can do and technical details.
Given the complexity of modern instruction sets hardware vendors moved to hardware designs incorporating complex decode units. A single instruction of the complex outwardfacing instruction set is translated to multiple instructions of the simpler internal architecture. While it is possible to do this translation in hardware alone, some instructions would require huge amounts of space on the silicon and increase costs. These complex instructions are instead decoded using a software-like approach called microcode. While processing such an instruction, the CPU internally evaluates a sequence of operations, micro-ops, which decode the complex instruction into the corresponding simpler operations that are performed by the hardware. In the light of the existence of hardware bugs such as the infamous Pentium fdiv bug, hardware vendors developed a process to fix those errors without requiring a CPU replacement. However the microcode is stored in a ROM on the CPU die and can not be changed after production. Also relatively simple or often used instructions are still decoded in hardware. The update is instead achieved using microcode updates, which intercept certain instructions and replace their faulty implementation with a new, fixed version. These updates are applied either by the BIOS/UEFI or the operating system during early bootup. While the update process is well documented, the Linux kernel offers a module for it, and the updates are provided by the CPU vendors, the actual semantics of microcode are proprietary. Most update mechanisms are protected by signatures or other cryptographic primitives. However there were some indications that older CPU models (until around 2013) do not have a strong cryptographic protection and thus would accept custom updates. Given this chance we started to analyze the behavior of the CPU given our own updates and used these observations to infer the semantics of microcode. After some time we reverse-engineered enough of the semantics to write our own microcode programs. These programs range from very simple proof of concepts to stealthy backdoors and defensive primitives. As an additional approach we also performed hardware analysis. By delayering the CPU and imaging it with both an optical and an electron microscope we could locate and read out the ROM containing the microcode. After processing and reordering the physical connections we retrieved the hardwired microcode of the CPU. This gave us more information on what can be done with microcode and allowed more insights into the intended behavior than our reverse-engineering approach. In this talk we will first start with a (short) crash course in CPU architecture and where microcode is used in practice. We will then cover our reverse engineering methods and how we were able to discover the semantics of x86 microcode. We then demonstrate, also with live demos, this knowledge with multiple microcode programs that implement both defensive measures as well as provide an attacker with hard to detect backdoors. Lastly we will discuss security problems and possible solutions to protect against them. We also provide example microcode programs for your own CPUs (use at your own risk) and a kernel patch to apply them on a Linux system. Also we will have some systems with us so you can try your hand at writing some microcode yourself.

Additional information

Type lecture
Language English

More sessions

12/27/17
Security
oranav
Saal Dijkstra
How I hacked Sasmung eMMC chips: from an indication that they have a firmware - up until code execution ability on the chip itself, relevant to a countless number of devices. It all started when Samsung Galaxy S3 devices started dying due to a bug in their eMMC firmware. I will cover how I figured out there's a firmware inside the chip, how I obtained it, and my journey to gaining code execution on the chip itself — up until the point in which I could grab a bricked Galaxy S3, and fix it ...
12/27/17
Security
Mathias Dalheimer
Saal Adams
Wir retten das Klima mit Elektroautos — und bauen die Ladeinfrastruktur massiv aus. Leider werden dabei auch Schwachstellen auf allen Ebenen sichtbar: Von fehlender Manipulationssicherheit der Ladesäulen bis hin zu inhärent unsicheren Zahlungsprotokollen und kopierbaren Zahlkarten. Ladesäulenhersteller und Ladenetzbetreiber lassen ihre Kunden im Regen stehen — geht das schnelle Wachstum des Marktanteils zu Lasten der Kundensicherheit?
12/27/17
Security
Filippo Valsorda
Saal Dijkstra
The Go implementation of the P-256 elliptic curve had a small bug due to a misplaced carry bit affecting less than 0.00000003% of field subtraction operations. We show how to build a full practical key recovery attack on top of it, capable of targeting JSON Web Encryption.
12/27/17
Security
Artem Kondratenko
Saal Clarke
Year 2017 was rich in vulnerabilities discovered for Cisco networking devices. At least 3 vulnerabilities leading to a remote code execution were disclosed. This talk will give an insight on exploit development process for Cisco IOS for two of the mentioned critical vulnerabilities. Both lead to a full takeover of the target device. Both PowerPC and MIPS architectures will be covered. The presentation will feature an SNMP server exploitation demo.
12/27/17
Security
Saal Borg
Positive Technologies researchers Maxim Goryachy and Mark Ermolov have discovered a vulnerability that allows running unsigned code. The vulnerability can be used to activate JTAG debugging for the Intel Management Engine processor core. When combined with DCI, this allows debugging ME via USB.
12/27/17
Security
argp
Saal Clarke
This talk presents the technical details and the process of reverse engineering and re-implementation of the evasi0n7 jailbreak's main kernel exploit. This work was done in late 2013, early 2014 (hence the "archaeology" in the title), however, it will provide insight into the kernel debugging setup for iOS devices (iDevices), the encountered difficulties and how they were overcome, all of which can be useful for current iOS kernel vulnerability research.
12/27/17
Security
Saal Dijkstra
Do you want to learn how modern binary code obfuscation and deobfuscation works? Did you ever encounter road-blocks where well-known deobfuscation techniques do not work? Do you want to see a novel deobfuscation method that learns the code's behavior without analyzing the code itself? Then come to our talk and we give you a step-by-step guide.