In today's world, physical access to a device is considered a significant threat as devices often play a central role for the underlying business model. A multitude of assets, intellectual property (IP) and even the devices themselves have become sufficiently valuable to require adequate protection.
This gave rise to security features specifically designed to mitigate threats related to physical access. These type of security features, for example Secure Boot, are nowadays way more common than they used to be just a handful of years ago.
Nonetheless, modern device hackers did not give up, often resorting to powerful techniques like Fault Injection (FI) in order to circumvent these new defenses. For example, most of the latest gaming consoles, if not all, have been initially hacked successfully using a wide variety of FI attacks in order to achieve code execution, escalate privileges or extract cryptographic keys.
At the same time, lots of research has been published where FI theoretics and practicalities are discussed and demonstrated. We have been specifically active in this field, for example demonstrating that FI is an efficient technique for bypassing Secure Boot and escalating privileges on Linux.
We expect that FI attacks will become even more relevant in the future as more devices will implement defenses to prevent easy access to device internals.
Background
The basic concept of FI is actually quite straightforward. Simply said, it often boils down to using specialized tooling for injecting a glitch at a specific moment in time into a vulnerable target. Some call it magic, while others like to fall back on their understanding of the physics at play.
Actually, most FI details are not that easy to discuss, even for seemingly simple attacks. In fact, quite a diverse technical background, spanning multiple domains related to both software and hardware, is usually required to fully digest the matter at hand. Importantly, a thorough understanding of the details is often needed to come up with novel ideas that progress the FI research field.
This is something we experienced ourselves in numerous exchanges between us and with others. Discussing FI attacks is not always trivial, mostly due to a mix of different backgrounds, levels of understanding and experience. We realized we needed a better method or tool to support reasoning on FI attacks and defenses.
We believe that our Fault Injection Reference Model (FIRM), which we introduced already at HITB+CyberWeek and POC2019, does exactly that.
Before we dive into FIRM itself, let's align ourselves on what a FI vulnerability exactly is and how attackers utilize FI for attacks.
What's a FI vulnerability?
Most attacks, if not all, are applicable due to the presence a vulnerability. Without a vulnerability, it would be hard to differentiate a feature from an actual attack. While software vulnerabilities have been refined conceptually over the years, no comparable effort has been devoted to FI vulnerabilities.
Without any attempt to be rigorous or complete, we like to use the following definition for describing a FI vulnerability.
"The susceptibility of a hardware subsystem to a specific
Fault Injection technique, which has an impact on security." - Raelize
It should already be apparent from the definition itself that bypassing Secure Boot using voltage glitches entails exploiting a different vulnerability than doing the same using optical pulses. Although the achieved goal is identical, the underlying physics and root cause is entirely different. It's important to point out that these differences become extremely relevant during the development of both effective attacks and defenses.
Interestingly, specialized tooling is not always required to trigger FI vulnerabilities. Examples are CLKSCREW and Rowhammer which both use software to trigger FI vulnerabilities. Moreover, these attacks showed that FI vulnerabilities are applicable to more than just the CPU alone.
We consider these so-called software-driven attacks to be FI attacks and they fit perfectly in FIRM as well!
What's a FI attack?
At a high level, the steps an attacker takes for performing a FI attack are quite intuitive. Most FI attacks can be summarized as follows:
- Select a target
- Select a FI technique
- Generate a trigger
- Glitch n' pray
- Profit
For many attacks, there is not much more to it. It would not be the first time the security of a modern chip is completely compromised by using this naive, but straightforward, approach. Nonetheless, seasoned FI practitioners know that this process is not always sufficient. At some point the need comes to better understand what exactly is going on.
Regardless if you are an attacker or defender, the nuances of the variables at play become very important when targets are complex or specifically hardened against FI. This includes for example the timing of the glitch, the shape of the glitch, the impact of the glitch, the target's state, etc.
We raelized we could visualize FI attacks, identify their main building blocks and conceptually play with them. Moreover, we could visually break down the attack to discuss specific nuances and details, but also capture common properties at a more abstract level. With time, experience and research the different pieces started falling into place and a reference model formed in our heads.
Simply said, FIRM was born.
Description of FIRM
We consider six so-called stages of a FI attack: Activate, Inject, Glitch, Fault, Exploit and Goal. These stages, or building blocks, are used to break down a FI attack in separate steps or events.
From an attacker's point of view, at the start, there are several choices to be made. These are likely steered mostly by attacker's capabilities (i.e. what tooling or expertise is available) and the characteristics of the target (i.e. some FI techniques may be difficult to apply).
- The Activate stage applies to the FI technique, whether driven by software or hardware, that is used.
- The Inject stage applies to the environmental domain affected by the FI technique.
- The Glitch stage applies to the parameters that can shape the glitch used to trigger the FI vulnerability in the target.
The above stages encompass what is required during the FI attack in order to trigger the FI vulnerability. The remaining stages are related to what can be accomplished once the FI vulnerability is triggered.
- The Fault stage applies to the type of faults that are introduced as a consequence of the FI vulnerability. These so-called Fault Models describe the behavioral impact (i.e. fault) a glitch has on a target (e.g. instruction skipping, instruction corruption, etc.)
- The Exploit stage describes how a given fault can be leveraged by an attacker to achieve a certain goal.
- The Goal stage describes what can be achieved by an attacker. These goals may be very similar to goals achieved with the exploitation of a software vulnerability.
At each stage there is a vast amount of available options and potential outcomes. The picture below presents by no means an exhaustive list. Nonetheless, it gives a peek in the kitchen for the amount of variables at play while conducting FI attacks.
The choices made during the Activate, Inject and Glitch stage impact the options available in the Fault, Exploit and Goal stage. Therefore, it's extremely important to sufficiently explore the available options during the initial stages before ruling out a certain attack as not applicable. Suboptimal choices will likely lead to suboptimal results.
It's typically much easier to prove a FI attack is possible rather than proving it's impossible. Negative proofs may be even impossible…
Using FIRM – Describing attacks
FIRM can be used for effectively describing FI attacks. We demonstrate it here using some real-world attacks as an example.
Bypassing Secure Boot on the Nintendo Switch
This publication shows it's possible to bypass the Secure Boot feature of the Nintendo Switch using FI. The attacker used a home-made, FPGA-based, glitcher to inject glitches into the chip's voltage supply. The attack goal was to bypass the verification of the bootloader in order to extract the decryption keys for some of the contents stored in flash.
We can describe the attack using FIRM:
As far as we know, details regarding the fault itself were never disclosed. From an offensive perspective this is not uncommon. Attackers are often not that interested in what exactly is affected within a chip. In the end, knowing the fault model itself is often not needed for reaching the goal.
Nonetheless, a better understanding of the faults at play gives way to more powerful attacks, which will become more relevant once manufacturers start hardening their devices.
Escalating privileges using Rowhammer
This publication from Google's Project Zero (P0) demonstrates how the Rowhammer vulnerability can be used to gain Linux Kernel privileges. The authors used software to trigger the hardware vulnerability in the DRAM chip in order to perform this FI attack.
Using FIRM, we can describe this FI attack as well:
Using FIRM – Designing defenses
FIRM can also be used from a defensive perspective. This can be useful while designing defenses against FI attacks.
The picture below shows how typical FI defenses can be actually connected to different FIRM stages. It should become more visible how different measures can play a different role in lowering the chance of success, depending the stage they are connected to.
Manufacturers often consider FI specific defenses to lower the risk of FI attacks. FIRM allows them to consider what defense may be useful during what stage of a FI attack. Interestingly, some of the defenses applicable against FI attacks may not be specific to FI at all (e.g. software exploitation mitigations).
It's important to point out an interesting observation. For example, software mitigations do not affect FI attack until the Exploit stage is reached. This is both an advantage and a disadvantage. Because the Exploit stage occurs after the Fault stage, software mitigations are often tailored to a specific Fault Model. However, if not all possible Fault Models are known in advance, which is likely for a given target, then designing comprehensive software mitigations becomes not trivial at all. Having all the possible fault models by software mitigations may even be an impossible task per se.
Assuming the amount of applicable Fault Models is unknown, then effective defenses can only be implemented at the Inject or Glitch stage. The focus should shift from mitigating the exploitation to preventing or detecting the glitch before the hardware vulnerability is triggered at all.
There are many other interesting observations to be made. We leave this up to the reader for now. We will likely touch upon this observations ourselves at a later stage…
Using FIRM – Developing attacks
FIRM can also be used to envision and reason about new and unexplored attack paths.
For instance, in the diagram below, the exploitation path is independent from the path taken to trigger the vulnerability. Different FI techniques trigger different vulnerabilities but result in the same type of fault. This allows for reusing the same exploit path across different attacks.
Recently we came across an applicable example. The Secure Boot implementation of the ESP32 chip has been bypassed using both voltage glitches (reference) and electromagnetic glitches (reference). It's likely both attack trigger different hardware vulnerabilities but still use a similar path for exploitation.
Another interesting example is the JackHammer attack, where the Rowhammer vulnerability is triggered from an embedded FPGA instead of software. Effectively, the only difference between this attack and P0's Rowhammer attack is the Activate stage. All the remaining stages are applicable and can be reused.
Conclusion
We believe FIRM is useful for discussing FI attacks and defenses in a systematic manner. We are confident it can be used to progress both the offensive and defensive FI playing field. Nonetheless, we are aware that there is room for improvement and we are open to your remarks and/or contributions.
You can expect new FI research soon where we are going use FIRM again. Stay tuned!