Software Fault Encouragement
The Software Fault Encouragement (SFE) project aims to improve the security of legacy cyber systems by turning exploitable software errors into fail-stop conditions while imposing minimal run-time overhead. Turning errors into fail-stop conditions prevents large classes of cyber attacks and minimizes the exploit window available to attackers. In systems with built-in fault tolerance, this cyber defense improves system resilience. Our approach uses binary rewriting to emphasize and exploit the inherent brittleness of software systems to cause them to fail quickly when under attack.
Brittleness in Software
One of the key concepts behind SFE is the notion of software brittleness. This idea is based on the observation that, for most compiled software, small deviations from the expected values of code or data will cause errors. For example, array indexing operations can be thought of as brittle: a simple off-by-one error can lead to undefined behavior in programs. It is often these boundary cases that live on the edge of undefined behavior that act as gateways into cyber systems. By turning undefined behavior into fail-stop conditions, SFE aims to help prevent attackers from using these errors to subvert systems.
The project aims to enhance the brittleness of existing systems in two ways. First, we will employ some of the techniques developed for synthetic program diversity. Code layout and instruction selection randomization, for example, can thwart code reuse attacks that rely on precise knowledge of instruction locations. We will also add brittleness to binaries by exploring binary transformations that change program semantics. For example, we are able to turn certain uses of overflowed machine words into crashes before the overflowed value is used in a sensitive computation. This transformation can prevent information disclosure or corruption attacks.
Applications to Real-Time Systems
Our approach has a number of important properties that make it especially well-suited to real-time systems:
- The transformations we apply impose low overheads on space and execution time budgets.
- The protections provided by our approach are enforced as passive side effects of execution; there is no monitoring process that can be subverted.
- Many real-time systems have built-in fault tolerance and recovery mechanisms, which allow them to quickly recover to a known-good state after a crash.
Fault tolerance is a particularly powerful tool for maximizing the effectiveness of software brittleness. Software brittleness by itself can help provide confidentiality and integrity to a system by preventing attacks. Combined with a suitable fault tolerance mechanism, software brittleness need not have a negative impact on availability.
This project aims to protect critical systems from cyber attacks. As these systems are critical, there is an even stronger obligation than normal to build an assurance case that we do not break systems in the process of protecting them. We aim to employ equivalence checking to ensure that our transformations preserve the functionality of the original system. Many transformations we aim to apply are semantics preserving and are amenable to standard equivalence checking techniques. However, some transformations are not semantics preserving: they will intentionally introduce new crashes in the presence of malicious inputs. To build assurance in these cases, we will check for equivalence modulo expected side conditions and create human readable descriptions of the expected differences.
The Software Fault Encouragement project aims to explore the use of software brittleness as a cyber defense mechanism. Along the way, it aims to bring the state-of-the-art in binary analysis and rewriting to practical and deployable tools, with the assurance of cutting-edge formal methods research.
This material is based upon work supported by the Office of Naval Research under Contract No. N68335-17-C-0241.
Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the Office of Naval Research.