Etienne Louboutin

Software sensitivity to control flow hijacking

Introduction and summary of the research

Software security can be taken into account right from the design stage. This approach, known as security by design, enables action to be taken as early as possible in the design phase to influence the architecture of the software. Protection against attacks by hijacking the flow of execution, such as return-oriented programming, is not designed to change the way software is designed, but enables software to be protected either when it is compiled or by working directly on the binary produced.

In this thesis, we propose metrics that allow a developer to assess the sensitivity of software to execution flow hijacking attacks. To aid development, the metrics defined make it possible to identify software binary production parameters that lead to increased sensitivity to these attacks. The use of these metrics is illustrated in this thesis by studying the influence of compilers and their options, languages and hardware architectures.

State of the art and context

The first attacks based on code reuse were called return-to-libc and diverted the flow of execution to call functions present in the standard C library to carry out the attack. In 2007, Shacham published a generalisation of these attacks that did not use explicit function calls, called a posteriori ROP. This article also shows the ability of these attacks to be Turing-complete.

In 2012, the same team returned to the subject, clarifying the concepts and how to carry out these attacks, implement them and analyse a program to find out what is relevant. This generalisation applies to both SPARC and x86 architectures. They also show that the standard C library is sufficient to mount attacks for any purpose.

Actions relating to detection and protection against this type of attack

A number of solutions have been put in place to protect against this type of attack, which I have analysed.

Control Flow Integrity: A number of groups have begun work on possible ways of guaranteeing that a program's flow of execution is as expected. A publication from Microsoft [1] introduces an initial protection that guarantees that the execution flow has not been hijacked. This protection protects certain types of redirection, thus protecting indirect function calls. It is a limited protection against flow change, which does not protect against most forms of POR. Their solution has the advantage of being transparent, involving almost no operation overhead, and requiring only a slight modification to the compiler.

Code Pointer Integrity: Another group has worked [3] on both static and dynamic checking of all pointers present in a code, to determine whether they need to be protected, such as pointers to functions, used in all calls, jumps and ret. Generic pointers (void \* and char \*) need additional analysis to determine whether the pointer needs to be protected. Protection is based on an additional separation of memory by guaranteeing a memory zone considered as protected, in which the necessary pointers will be placed, and whose value will be checked at runtime. This solution is implemented with a modification to the compiler and unmodified sources. The reduction in execution performance is around 1% with low pointer protection (call, jump, ret) and 3% to 10% with higher protection. In both cases, attacks using basic ROP are rendered impossible.

PICON: A different solution, proposed by ANSSI [2], uses an external monitor to oversee all function calls and returns within a program. Each input and output sends a signal, which is received by the monitor to check its consistency with the last received signals. This technique has minimal impact on performance as long as only call and ret instructions are protected. However, when jumps are also protected, performance drops significantly. Additionally, their tool has only been tested on non “multi-threaded” programs.

 

General Objectives and Future Actions

A cybersecurity awareness seminar was conducted for the staff at Thales Cholet.

An in-depth study of protection solutions against ROP attacks is planned for the coming month.

The main objectives currently defined include the static analysis of a system comprising one or more software components and hardware to gather insights into the feasibility of conducting an ROP attack on the system.

Another key objective is to establish a behavioral model of a system and develop an analyzer capable of detecting abnormal executions to report relevant information.