Control Flow Integrity

Outline
❏ Stack Corruption Techniques

❏ CFI Implementation Techniques

❏ Our Approach of CFI Implementation

❏ CFI Violation and Detection

❏ Future Directions
Program Execution (Expected Behaviour)
❏ Each node represents function
in the program

❏ Function which calls another

function is known as caller

❏ Function which is called is

known as callee
Malicious Behaviour
❏ Function malicious() is not part
of the application program

❏ Program control is not supposed

to reach malicious() function
Stack Corruption Techniques

1. Corrupting callee-saved registers

2. Corrupting function call return address

3. Code injection

4. Buffer overflow

5. Return-to-libc

6. Unsafe function: strcpy()

Mitigation Techniques

1. StackGuard: Canary

2. ASLR (Address space layout randomization)

3. Unsafe function strcpy() replace with safe function strncpy()

4. PointGuard
What is CFI?
❏ CFI is a mitigation technique, which enforces a program to follow pre-defined
path of execution

❏ Definition: software execution must follow its execution path

What is CFI Violation?
❏ Change in the execution path of a program can be used by an adversary to
execute malicious code

❏ Methods to change execution path of a program

❏ Code injection

❏ Buffer overflow

❏ Return-to-libc

❏ Malicious user
Existing CFI Techniques
1. CFI (Control Flow Integrity) with Label Checking

2. CCFIR (Compact Control Flow Integrity and Randomization)

3. CCFI (Cryptographically-enforced Control Flow Integrity)

4. CFCSS (Control Flow Checking by Software Signature)

1. CFI with Label Checking
❏ Labels are used to
identify correct
destination function
1. CFI with Label Checking
❏ Rely on
instrumentation of
assembly code of a
program using
following types of
labels
❏ Label ID

❏ Call ID DST

❏ ret ID
1. CFI with Label Checking
❏ It uses labels (unique
number)

❏ Assign a label at the start

of each callee function

❏ Labels are compared

during function call and
return call
1. Drawbacks
❏ Instrumentation is not possible all the time

❏ It does not provide integrity of control-flow

2. CCFIR
❏ Compact Control Flow Integrity and Randomization

❏ Enforcement by redirecting control flow transfer through new code section

called "Springboard"

❏ Function calls and return calls are directed through the Springboard
2. CCFIR
2. Drawbacks
❏ Compatibility issue:
call from protected
to unprotected
module fails

❏ Rewriting every
module is not
possible all the time
3. CCFI
❏ Cryptographically-enforced Control Flow Integrity

❏ It protects function pointer and return address with the help of Message
Authentication Code (MAC)

❏ MAC (K, pointer, class)

❏ K is a secret key

❏ pointer is function pointer or return address

❏ class is a flag to identify between function pointer and return address

3. CCFI
❏ Whenever return address is stored in memory, MAC is calculated and stored
in memory. During run-time, MAC is re-calculated and compared with stored
MAC
3. Drawbacks
❏ When an adversary changes
return address on the stack, old
and new MACs do not match,
and an error is thrown

❏ When an adversary knows an old

value of MAC, he can hijack the
control-flow of the program
4. CFCSS
❏ Control Flow Checking by Software Signature

❏ Program is divided into basic blocks called nodes (blocks = functions)

❏ During compile-time, each node is assigned an unique number called

“software signature”

❏ This technique is used to check correct control-flow between two nodes, i.e.,
between source (caller) and destination (callee)
4. CFCSS
4. CFCSS
❏ Signature difference (d) is XOR
signature of source and destination
nodes. It is calculated at compile time

❏ Runtime signature (G) is XOR of

signature difference (d) and signature
of source node. G is calculated during
runtime

❏ Runtime signature must match with

signature of destination node for
correct branching
4. Drawbacks
❏ Constraint: an unique number
(signature) is assigned to each
node

❏ Same signature is assigned to

two nodes in branch-in-fan node

❏ V5 is branch-in-fan node
Drawbacks of Existing CFI Techniques

❏ Do not have protection against return pointer over-writing

❏ We propose our CFI technique which ensures control flow integrity for any
program for which the source code is available
Our CFI Implementation

1. Derive CFG (Control Flow Graph) of a program

2. Derive regular expression of the program

3. Check for CFI violations at run-time

What is a CFG?
Our Approach to Derive a CFG
❏ We use egypt-tool (version 1.1.0)

❏ It delegates the source code analysis to GCC

❏ gengraph -o graph -t pn main.c

❏ gcc -finstrument-functions -std=c++0x -c -o main.o main.c

❏ g++ -g -rdynamic -std=c++0x -c -o trace.o func.cpp

❏ g++ -g -rdynamic -std=c++0x trace.o main.o -o cfimonitor

DOT file of CFG
Matrix List of CFG
Algorithm to Derive Regular Expression of a CFG
❏ We use Brzozowski’s algorithm to generate regular expression of CFG

❏ It creates system of linear equations. By solving system of linear equations,

regular expression can be obtained

❏ Algorithm is divided into two parts:

❏ First part is to convert CFG to Deterministic Finite Automata (DFA)

❏ Second part is to convert DFA to regular expression

Example: Deriving Regular Expression of CFG

Regular Expression:

main.(Division.Display | Addition)

Valid paths of execution:

1. main->Division->Display
2. main->Addition
Deriving Regular Expression of CFG
Regular Expression:
main.(Division.Display | Addition)

Invalid path of execution:

main->Addition->Display
Checking for CFI Violation

Function call (expected behaviour) Function call (CFI violation)

Checking for CFI Violation

Function return (expected behaviour) Function return (CFI violation)

Checking for CFI Violation
❏ Our CFI approach enforces control-flow of a program to follow the paths in
given CFG

❏ We take help of regular expressions to detect CFI violations

❏ A CFI violation can be defined as

❏ An undefined change in the control-flow of execution, or

❏ Calling a function that is not a part of the program

❏ Execution path which does not satisfy regular expression is invalid path of control-flow

❏ We have designed a monitor function to guarantee CFI

Monitor Function
Monitor Function
1. Initialization: generate regular
expressions from the DOT file

2. Function instrumentation:

3. It monitors all states in the

control flow of a program
Monitor Function
1. Monitor Initialization mainly
includes generation of regular
expression from CFG

2. Whenever function call or

return statement is executed,
monitor function is called
Function Instrumentation
❏ Entry point: void __cyg_profile_func_enter (void *, void *)
❏ Function name is fetched using backtrace()
❏ Assign unique number to each function
❏ Function call chain must satisfy regular expression

❏ Exit point: void __cyg_profile_func_exit (void *, void *)

❏ __builtin_return_address() is used to fetch return address
❏ Checking return address integrity
Buffer Overflow
Jump to Adversary Function
Skipping Function Call
Conclusion
❏ CFI is simple and trustworthy mitigation technique. Over the years powerful
attacks have been invented that make the adversary more powerful

❏ Our CFI implementation ensures that with help of regular expressions and by
checking integrity of return address, control flow integrity of program can be
maintained

❏ CFI implementation needs to be strengthened against many other attacks.

Overhead is always important parameter for any technique. Overhead can be
reduced
References
1. Martin Abadi, Mihai Budiu, Ulfar Erlingsson, Jay Ligatti. Control-flow integrity. In Proceedings of the 12th
ACM conference on Computer and communications security, CCS, 2005.

1. Mauro Conti, Stephen Crane, Lucas Davi, Michael Franz, Per Larsen, Marco Negro, Christopher
Liebchen, Mohaned Qunaibit, Ahmad-Reza Sadeghi. Losing Control: On the Effectiveness of Control-
Flow Integrity under Stack Attacks. In Proceedings of the 22nd ACM SIGSAC Conference on Computer
and Communications SecuRity, 2015.

1. Tyler Bletsch, Xuxian Jiang, Vince Freeh. Mitigating Code-Reuse Attacks with Control-Flow Locking. In
Proceedings of the 27th Annual Computer Security Applications Conference, 2011.

1. Mark M. Seege. Using Control-Flow Techniques in a Security Context: A Survey on Common Prototypes
and Their Common Weakness. In Proceedings of the 2011 International Conference on Network
Computing and Information Security, 2011.
References
1. Ali Jose Mashtizadeh, Andrea Bittau, David Mazieres, Dan Boneh. Cryptographically Enforced Control
Flow Integrity. In proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications
Security, CCS, 2015.

1. N. Oh, P. P. Shirvani, E. J. McCluskey. Control-flow checking by software signatures. IEEE

Transactions on Reliability, 2002.

1. Chao Zhang, Tao Wei, Zhaofeng Chen, Lei Duan, Laszlo Szekeres, Stephen McCamant, Dawn Song,
Wei Zou. Practical Control Flow Integrity and Randomization for Binary Executables. In proceeding SP
13 Proceedings of the 2013 IEEE Symposium on Security and Privacy, 2013.

1. Sibel Toprak. Intraprocedural Control Flow Visualization based on Regular Expressions. Hamburg
University of Technology (TUHH), 17 Jan 2014.
References
1. Hardware is the new software https://www.microsoft.com/en-us/research/wp-
content/uploads/2017/05/baumann-hotos17.pdf

1. Function Instrumentation
https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html

1. egypt tool
https://www.gson.org/egypt/

1. Return-to-libc
https://en.wikipedia.org/wiki/Return-to-libc_attack