IS561 Project Report ParisDakarTech:

Backward-edge Protection:

Improvements on SafeStack and RETGUARD

Alexis Gacel, Ndeye Khady Ngom, Kai Lüke

ABSTRACT

The integrity of return addresses pushed to the stack is

the oldest target of control flow attacks. No mainline

compiler offers defenses for attacks that find the posi‐

tion of the return address and replace its content with a

shadow stacks (Intel) or fast pointer authentification

(Qualcomm). But until then sensible applications with‐

out highest performance requirements can make use of

our software solution.

1. INTRODUCTION

Many mitigation ideas have been implemented

since the first steps were taken to defend against

stack smashing attacks. Still, stack canaries are the

established choice of C compilers and enabled by

default. But besides buffer overflows there are many

Not all security-sensitive programs have perfor‐

mance as high goal and for others the advancement

of processor speed should have compensated the

impact of of more secure solutions. Looking at the

two big free software compilers GCC and Clang it is

surprising to see that only SafeStack [6] from CPI/

CPS [16] got upstreamed into Clang. Safestack

maintains an additional unsafe stack for buffers and

objects with leakable pointers. At least OpenBSD

patched their Clang version recently with RET‐

like the ProPolice canary that finally landed in GCC,

or XOR random canaries that XOR the return ad‐

dress with the canary. Pointguard was an approach

to XOR all code pointers with a canary before they

are saved to memory [2]. This attempt hurts com‐

patibility and was therefore abandoned, in addition

it is also vulnerable to leaks. StackShield imple‐

mented a shadow stack. The calling convention on

SPARC allowed StackGhost to add a kernel handler

for frame spills in order to introduce a XOR of the

available backward-edge protection which we dis‐

cuss here [1]. The CFI version of Clang [7] does only

mention a proposal in the design document to ex‐

tend it further to backward-edge CFI for return

statements [8].

The PaX team sells grsecurity RAP [12] which in‐

troduces CFI for user and kernelspace. This CFI is

based on function types and also used for return

target verification, where in addition an in-register

XOR canary of the return address is kept. But in

AES-NI HMACs based on a secret key, the return

address, and the RBP. Even though known-plaintext

attacks are circumvented, a replay attack scenario is

left where a previously valid address can be rein‐

jected in an invalid context. As a custom LLVM pass

it stores the key and AES variables in the

xmm regis‐

ters and breaks ABI compability.

Qualcomm announced an ARM 8.3 pointer au‐

thentification ISA extension that offers hardware

the processor and have to be managed by the kernel

per process.

Microsoft included Return Flow Guard (RFG) [5]

as shadow stack solution but discontinued this

project because the API design was vulnerable to

leaks and the region itself writable [15]. Instead co‐

operation with Intel was started for Intel’s hardware

stack protection.

Intel announced its Control-flow Enforcement

Technology (CET) [14] as transparent hardware

are available.

This project should implement and evaluate

strong return address protection in software. This is

considered meaningful for sensitive applications be‐

cause the hardware-based solutions are just emerg‐

ing at the horizon and will take years to arrive for

the majority of users.

2. SAFESTACK AND RETGUARD

We first study the current problems of SafeStack

and RETGUARD to see what properties a solution

moving buffers to a second memory region is small.

Instead of isolating memory regions, RETGUARD

only needs an additional XOR instruction in the

function prolog and epilog. It considers the RSP as

key to be secret so that appropriate XORed values

can not be forged by the attacker. But also reading

the XORed stack content reveals the RSP if the tar‐

get address is known (or the target address if the

RSP is known) due to the nature of the XOR opera‐

tion working in both directions.

The stack position can be found through neglected

pointers in libraries or the TCB, thread spraying or

the constant offset from TLS for secondary threads

[11]. On a simple implementation side channel at‐

tacks were possible, too [9].

In particular the relation of the TLS with sec‐

ondary threads was a motivation for us to see what

other offsets are constant. We found out that the un‐

safe stack has a constant offset to the stack of sec‐

ondary threads. We were also able to leak all sensi‐

return address integrity should mitigate against

overwriting the return address after the stack con‐

ed and a secure information storage. Thread local

storage (TLS) variables, in C declared with the

__thread prefix, can be declared with a initial val‐

ue which allows detection if a new thread was start‐

ed. For the safe storage place the TLS is not appro‐

priate because it is writable in memory and is

placed at the beginning of each secondary thread.

Since the System V 64 bit ABI does not guarantee

regular registers to stay untouched we considered

switching off AVX usage during compilation. This

sider these registers as safe because only our instru‐

mentation code will use them. Binary ROP gadgets

are irrelevant because they require that the control

flow hijack already took place.

Next we will describe the assembly instrumenta‐

tion framework, a RAP-like simple XOR pass, an

userspace shadow stack pass, an in-kernel shadow

stack pass and finally a pass with HMAC-based

cryptographic protection.

4.1 INSTRUMENTATION FRAMEWORK

strumentation passes are kept in separate files and

are specified as argument for the wrapper. An extra

layer of complexity is that for supporting shared ob‐

jects each pass needs to switch between the modes

of addressing the TLS variables. Also, a pass should

emit its global definitions only once.

# Set compiler for build scripts

# or manual invocation as $CC

export CC="$PWD/ccwrapper $PWD/pypass…"

For usage with a build system exporting the CC en‐

tion e.g. if the used instrumentation pass can only

follow strict LIFO semantics the stack. But our

framework may have other problems with opti‐

mized code, too.

The requirements for a pass are that it can be

called with these arguments by the wrapper:

./passXYZ [--shared] [infile] outfile

A pass modifies an input assembly file in AT&T

syntax and saves the result as output file, where in‐

put and output can be the same file. If no input file

# normal mode:

movq $1, %fs:var@tpoff

# vs.

# position independent mode:

leaq var@TLSGD(%rip), %rdi

callq __tls_get_addr@PLT

movq $1, (%rax)

Using Intel syntax turned out to be too compilicated

and lead to inconsistencies due to implicit assump‐

tions in the compilers that expect AT&T and when

The variable entry contains instrumentation for the

function prolog, ret for the epilog.

The simplest pass is just an empty bash script that

does nothing. We also reimplemented RETGUARD

as pass to be independed from LLVM builds which

led to a high difference in runtime speed depending

on the version that is used. The following sections

describe all other passes.

4.2 SIMPLE XOR PROTECTION

We can improve RETGUARD with a secret key in‐

up is done in a helper function which uses the

trandom syscall and then stores the random key

into the x87 register stack. At each function entry

and exit the key is changed with a constant (or the

RSP) in order to generate a temporary key for this

function, as a weak mitigation of the most simple re‐

play attacks. This updated key is stored back into

the safe register. The prolog ends with cleaning the

key from the memory and general register where it

which allows to modify an observed XORd return

address to be used in a different function frame. But

since XOR is used the whole solution anyway leaks

the current key if the plain return address is known.

If a secure hash function would be used to generate

a unique temporary key that can not be used to

compute a temporary key of another function

frame, then there is no point in using XOR anymore

because a secure hash is already everything needed

for a HMAC solution that is resilient against known

could be recommended for performance reasons.

4.3 SHADOW STACK

Shadow stacks in the program memory have the

challenge that they are writable. Resetting the map‐

ping permissions in each function entry and exit is

costly because it would involve system calls (but

easy to add if needed). Our solution aquires a new

memory region from the kernel at a random posi‐

tion through ASLR. The pointer to this stack is only

stored in the safe register which is never leaked.

based on the current RSP and skip the update. This

would also solve the problem that strict LIFO se‐

mantics break some higher compiler optimization

levels. Currently the return address on the stack is

compared with the shadow stack copy, a mismatch

lets the program abort. One could also decide to

overwrite the original return address to hide a code

pointer. Attack detection can still be done by ob‐

serving changes in the overwritten value which

could be just zeros or the RSP. Access to two memo‐

change in the memory layout of the function. Like

Qualcomm we use the static bits of the address to

introduces more unknown bits for the attacker in

the HMAC.

Therefore we implemented our last variant with a

fast non-cryptographic hash function [13] and the

additional XOR. Under the assumption that a strong

cryptoanalysis is unlikely this is our most promising

approach.

Replay attacks are still possible but including the

RSP into the hash limits them to the same position

the hash would further narrow this down to return

5. EVALUATION

Both shadow stacks and pointer authentification are

strong mitigation techniques that offer integrity for

return addresses. Based on examples we will

processes serveral requests in the same connection.

The client communication is handled in a new

thread. We chose a format string vulnerability be‐

cause it first leaks registers and then the stack for

higher arguments. A client requests files by specif‐

ing their names and the format string vulnerability

occurs when the server uses these filenames in its

answer. The answer is always that there is no such

file. Instead of having to use the format string attack

when overwriting the return address we included a

the return address. It also leaks

stdin which could

be used to get the address of system() but instead

of needing ROP to set up the argument we included

the function success that starts a shell, so that a

simple code pointer offset is enough to determine

the new return address. Here is a simple extract of

the vulnerable function:

char buf[70];

char response[100];

&& buf[0]!='\n') {

snprintf(response+len, 70, buf);

fwrite(response, 1, strlen(response), out);

// insert easy write primitive here

fprintf(out, "\nGET ");

}

An exploit can either use the unsafe stack pointer or

the RBP to calculate the RSP value when the func‐

tion returns because both have a constant offset. Ex‐

ploiting RETGUARD is straightforward though

though the return address is XORed with a secret,

we can calculate the expected return address

though the leaked static string pointer, and in re‐

verse then even get the key through a XOR. This al‐

lows us to XOR the malicious target address with

the key and use it to overwrite the return address.

The two shadow stacks and the RC4 or fast hash

HMAC authentification can not be exploited be‐

cause of strong isolation for the kernel shadow

stack, for the userspace shadow stack because of the

ples/vuln.c and an automated exploit in exam‐

ples/vuln-exploit.

5.2 PERFORMANCE

We measured the runtime of common programs to

get an impression of the performance impact of the

presented solutions. Microbencharks of the dura‐

tion of prolog and epilog would also be possible in

order to be independent from the number of call/

return pairs in the programs. In literature the run‐

time increasement for shadow stacks varies a lot

is more significant than the slowdown. Out of our

secure solutions the userspace shadow stack offers

the best performance with a runtime of factor 3–25.

The in-kernel shadow stack resulted in a runtime of

factor 4–40. Our RC4-based HMAC turned out to be

very slow with a runtime of factor 38–190. The fast

HMAC with code pointer hiding has a runtime fac‐