Biblio

Code-reuse attacks (including ROP/JOP) severely threaten computer security. Control-flow integrity (CFI), which can restrict control flow in legal scope, is recognised as an effective defence mechanism against code-reuse attacks. Hardware-based CFI uses Instruction Set Architecture (ISA) extensions with additional hardware modules to implement CFI and achieve better performance. However, hardware-based fine-grained CFI adds new instructions to the ISA, which can not be executed on old processors and breaks the compatibility of programs. Some coarse-grained CFI designs, such as Intel IBT, maintain the compatibility of programs but can not provide enough security guarantees.To balance the security and compatibility of hardware CFI, we propose Transparent Forward CFI (TFCFI). TFCFI implements hardware-based fine-grained CFI designs without changing the ISA. The software modification of TFCFI utilizes address information and hint instructions in RISC-V as transparent labels to mark the program. The hardware module of TFCFI monitors the control flow during execution. The program modified by TFCFI can be executed on old processors without TFCFI. Benefiting from transparent labels, TFCFI also solves the destination equivalence problem. The experiment on FPGA shows that TFCFI incurs negligible performance overhead (1.82% on average).

At present, code reuse attacks, such as Return Oriented Programming (ROP), execute attacks through the code of the application itself, bypassing the traditional defense mechanism and seriously threatening the security of computer software. The existing two mainstream defense mechanisms, Address Space Layout Randomization (ASLR), are vulnerable to information disclosure attacks, and Control-Flow Integrity (CFI) will bring high overhead to programs. At the same time, due to the widespread use of software of unknown origin, there is no source code provided or available, so it is not always possible to secure the source code. In this paper, we propose FRCFI, an effective method based on binary rewriting to prevent code reuse attacks. FRCFI first disrupts the program's memory space layout through function shuffling and NOP insertion, then verifies the execution of the control-flow branch instruction ret and indirect call/jmp instructions to ensure that the target address is not modified by attackers. Experiment show shows that FRCFI can effectively defend against code reuse attacks. After randomization, the survival rate of gadgets is only 1.7%, and FRCFI adds on average 6.1% runtime overhead on SPEC CPU2006 benchmark programs.

The spread of the Internet of Things (IoT) and the use of smart control systems in many mission-critical or safety-critical applications domains, like automotive or aeronautical, make devices attractive targets for attackers. Nowadays, several of these are mixed-criticality systems, i.e., they run both high-criticality tasks (e.g., a car control system) and low-criticality ones (e.g., infotainment). High-criticality routines often employ Real-Time Operating Systems (RTOS) to enforce hard real-time requirements, while the tasks with lower constraints can be delegated to more generic-purpose operating systems (GPOS).Much of the control code for these devices is written in memory-unsafe languages such as C and C++. This makes them susceptible to powerful binary attacks, such as the famous Return-Oriented Programming (ROP). Control-Flow Integrity (CFI) is the most investigated security technique to protect against such threats. At now, CFI solutions for real-time embedded systems are not as mature as the ones for general-purpose systems, and even more, there is a lack of in-depth studies on how different operating systems with different security requirements and timing constraints can coexist on a single multicore platform.This paper aims at drawing attention to the subject, discussing the current scientific proposal, and in turn proposing a solution for an optimized asymmetric verification system for execution integrity. By using an embedded hypervisor, predefined cores could be dedicated to only high or low-criticality tasks, with the high-priority core being monitored by the lower-criticality core, relying on offline binary instrumentation and a light exchange of information and signals at runtime. The work also presents preliminary results about a possible implementation for multicore ARM platforms, running both RTOS and GPOS, both in terms of security and performance penalties.

The pervasive presence of smart objects in almost every corner of our everyday life urges the security of such embedded systems to be the point of attention. Memory vulnerabilities in the embedded program code, such as buffer overflow, are the entry point for powerful attack paradigms such as Code-Reuse Attacks (CRAs), in which attackers corrupt systems’ execution flow and maliciously alter their behavior. Control-Flow Integrity (CFI) has been proven to be the most promising approach against such kinds of attacks, and in the literature, a wide range of flow monitors are proposed, both hardware-based and software-based. While the formers are hardly applicable as they impose design alteration of underlying hardware modules, on the contrary, software solutions are more flexible and also portable to the existing devices. Real-Time Operating Systems (RTOS) and their key role in application development for embedded systems is the main concern regarding the application of the CFI solutions.This paper discusses the still open challenges and issues regarding the implementation of control-flow integrity policies on operating systems for embedded systems, analyzing the solutions proposed so far in the literature, highlighting possible limits in terms of performance, applicability, and protection coverage, and proposing possible improvement directions.

Runtime memory vulnerabilities, especially present in widely used languages as C and C++, are exploited by attackers to corrupt code pointers and hijack the execution flow of a program running on a target system to force it to behave abnormally. This is the principle of modern Code Reuse Attacks (CRAs) and of famous attack paradigms as Return-Oriented Programming (ROP) and Jump-Oriented Programming (JOP), which have defeated the previous defenses against malicious code injection such as Data Execution Prevention (DEP). Control-Flow Integrity (CFI) is a promising approach to protect against such runtime attacks. Recently, many CFI solutions have been proposed, with both hardware and software implementations. But how can a defense based on complying with a graph calculated a priori efficiently deal with something unpredictable as exceptions and interrupt requests? The present paper focuses on this dichotomy by analysing some of the CFI-based defenses and showing how the unexpected trigger of an interrupt and the sudden execution of an Interrupt Service Routine (ISR) can circumvent them.

Memory corruption errors in C/C++ programs remain the most common source of security vulnerabilities in today’s systems. Control-flow hijacking attacks exploit memory corruption vulnerabilities to divert program execution away from the intended control flow. Researchers have spent more than a decade studying and refining defenses based on Control-Flow Integrity (CFI); this technique is now integrated into several production compilers. However, so far, no study has systematically compared the various proposed CFI mechanisms nor is there any protocol on how to compare such mechanisms. We compare a broad range of CFI mechanisms using a unified nomenclature based on (i) a qualitative discussion of the conceptual security guarantees, (ii) a quantitative security evaluation, and (iii) an empirical evaluation of their performance in the same test environment. For each mechanism, we evaluate (i) protected types of control-flow transfers and (ii) precision of the protection for forward and backward edges. For open-source, compiler-based implementations, we also evaluate (iii) generated equivalence classes and target sets and (iv) runtime performance.

Memory corruption errors in C/C++ programs remain the most common source of security vulnerabilities in today's systems. Over the last 10+ years the security community developed several defenses [4]. Data Execution Prevention (DEP) protects against code injection – eradicating this attack vector. Yet, control-flow hijacking and code reuse remain challenging despite wide deployment of Address Space Layout Randomization (ASLR) and stack canaries. These defenses are probabilistic and rely on information hiding. The deployed defenses complicate attacks, yet control-flow hijack attacks (redirecting execution to a location that would not be reached in a benign execution) are still prevalent. Attacks reuse existing gadgets (short sequences of code), often leveraging information disclosures to learn the location of the desired gadgets. Strong defense mechanisms have not yet been widely deployed due to (i) the time it takes to roll out a security mechanism, (ii) incompatibility with specific features, and (iii) performance overhead. In the meantime, only a set of low-overhead but incomplete mitigations has been deployed in practice. Control-Flow Integrity (CFI) [1,2] and Code-Pointer Integrity (CPI) [3] are two promising upcoming defense mechanisms, protecting against control-flow hijacking. CFI guarantees that the runtime control flow follows the statically determined control-flow graph. An attacker may reuse any of the valid transitions at any control-flow transfer. We compare a broad range of CFI mechanisms using a unified nomenclature based on (i) a qualitative discussion of the conceptual security guarantees, (ii) a quantitative security evaluation, and (iii)\textbackslashtextasciitildean empirical evaluation of their performance in the same test environment. For each mechanism, we evaluate (i) protected types of control-flow transfers, (ii) the precision of the protection for forward and backward edges. For open-source compiler-based implementations, we additionally evaluate (iii) the generated equivalence classes and target sets, and (iv) the runtime performance. CPI on the other hand is a dynamic property that enforces selective memory safety through bounds checks for code pointers by separating code pointers from regular data.

Object flow integrity (OFI) augments control-flow integrity (CFI) and software fault isolation (SFI) protections with secure, first-class support for binary object exchange across inter-module trust boundaries. This extends both source-aware and source-free CFI and SFI technologies to a large class of previously unsupported software: those containing immutable system modules with large, object-oriented APIs—which are particularly common in component-based, event-driven consumer software. It also helps to protect these inter-module object exchanges against confused deputy-assisted vtable corruption and counterfeit object-oriented programming attacks. A prototype implementation for Microsoft Component Object Model demonstrates that OFI is scalable to large interfaces on the order of tens of thousands of methods, and exhibits low overheads of under 1% for some common-case applications. Significant elements of the implementation are synthesized automatically through a principled design inspired by type-based contracts.