1. Securing A Compiler Transformation
SAS 2016
Chaoqiang Deng (NYU) and Kedar Namjoshi (Bell Labs)
10-SEP-2016

2. Could Compilation Weaken Program Security?
Correctness does not imply Security!
Case in point: dead store elimination (DSE)
Why is this important?
Inherent difficulties for security validation
A correct & secure DSE procedure
Are other compiler transformations secure?
Long-term research goal:
A provably correct and secure production-quality compiler

3. Correctness ≠ Security
Dead Store Elimination (DSE) P
function act_on_password() {
x = read_password();
<< use x >>
x = 0; // clear secret
return; } Q
skip;
As P and Q have the same input-output behavior, the transformation is correct
It is, however, insecure, as the secret password is leaked through the stack in Q
This is the default behavior in GCC and LLVM; workarounds are either blunt or require deep compiler knowledge

4. Basic Questions
How difficult is it to check the security of a transformation (after the fact)?
Given programs P, Q, and a list D of eliminated stores, validating correctness is in PTIME but validating security is undecidable.
Any sound validator will be incomplete.
Is there a practical, provably secure DSE procedure?
New procedure, based on taint propagation and program structure.
Are other compiler transformations secure?
Theorem: For any transformation with a strict refinement proof, correctness implies security.
The important single static assignment (SSA) transform is insecure.

5. DSE Background Procedure Represent program P as a control-flow graph
Variable x is live at node p IFF there is a path from p in the graph with no writes to x up to a point where the value of x is read
Remove a subset of the dead (= not live) stores, replacing them with skip; the result is Q
Examples: (statements in red are dead stores)
x = 2; if (y > 50) {
x = 1; // x def
} else {
x = x+2; // x read }
<< use x >>
x = 2; if (y > 0) {
x = y+5;
x = y+10;
x = 2;
x = 5;
DSE is run multiple times, as other transformations (e.g., loop unrolling) may create dead stores.

6. DSE: Verifying Correctness with Translation Validation
Procedure: given input program P, resulting program Q, and a list of removed stores, D
Compute dead stores in P; check that this set includes all stores in D
Check that P and Q have bisimular control-flow graphs up to the labeling of edges in D
This procedure is in PTIME.
Induced refinement relation:
At corresponding program points p (in P) and q (in Q),
every live variable at p has identical values at p and q
x = 2; if (y > 0) {
x = y+5;
} else {
x = y+10; }
<< use x >>
skip; if (y > 0) {
x = x’ and y=y’
y=y’

7. Information Leakage and Secure Transformation
Consider a deterministic program P
Partition input variables into Low (L) and High (H) security
All state variables are low security
P leaks information if there are inputs (H=a,L=c) and (H=b,L=c) such that
the resulting computations of P produce different output OR terminate in different states.
We call (a,b,c) a leaky triple.
Example: for input values h=0, h=1, the final x-values differ.
High h
Low x initially 0
x = h;
if (h > 0) {
x = 10;
} else {
x = 20; }
A transformation from P to Q is secure if every leaky triple for Q is also leaky for P

8. DSE: Verifying Security with Translation Validation
Given input program P, resulting program Q, and a list of removed stores, D.
Theorem: Checking whether the transformation is secure is
PSPACE-complete if all variables have finite domains
Undecidable in the general case
Proof: a simple reduction from the halting problem. Given program P and input a.
Let P’ ::= {High input h; Low l initially 0; P(a); l = h; l = 0; }
Let Q’ ::= {High input h; Low l initially 0; P(a); l = h; skip; }
The transformation from P’ to Q’ with D = {“l=0”} is insecure if, and only if, P terminates on a

9. A Secure DSE Procedure
Combine two sources of information to determine which stores can be safely removed
Taint information (expressed via a Hoare-style proof system)
+ Program flow (in the form of dominance relations)
Consider a candidate dead store to variable x. It may be removed if:
The store is post-dominated by other stores to x
Justification: any leak through x must arise from the dominating stores
Variable x is untainted before the store and untainted at the exit from the program
Justification: the taint proof is unchanged, so a leak cannot arise from x; other flows are preserved
Variable x is untainted before the store, other stores to x are unreachable, and this store post- dominates the entry node

10. A Secure DSE Procedure: Case 2
Function foo () {
int x, y;
{x:U,y:U}
x = 0; // Dead Store
y = U:read_user_id ();
if (is_valid (y)) {
x = T:read_password ();
{x:T,y:U}
login (y,x);
x = 0; // Dead Store
} else {
printf ("Invalid ID"); }
return;
Variable x is untainted before the dead store and is untainted at the program exit.
Justification: the taint proof is unchanged, so a leak cannot arise from x.
All other flows are preserved.
sat Case 2

11. Are other compiler transformations secure?
Theorem: Any transformation from P to Q with a strict refinement relation is secure.
Let t ~L t’ if configurations t and t’ are from the same program and have identical low-state
A refinement relation R is strict if whenever R(t,s) and R(t’,s’), then t ~L t’ iff s ~L s’
(this is needed only at initial and final program points)
Several optimizations have strict refinements (DSE does not):
E.g., constant propagation, control-flow simplifications, loop unrolling
High password
Low x initially 0
x = password;
<< use x >>
x = 0;
x = x+5;
x = 5;
Constant
Propagation
s: x=5
s’: x=5
t: x=5
t’: x=5

12. SSA leaks information The secret password leaks out through x1.
High password
Low x initially 0
x = password;
<< use x >>
x = 0;
High password
Low x1 initially 0
Low x2 initially 0
x1 = password;
<< use x1 >>
x2 = 0;
SSA
The secret password leaks out through x1.
Possible resolutions
Clear all potentially tainted variables before register allocation: inefficient?
Modify SSA to carry auxiliary information about leakage: how?

13. Summarizing Main Results
Compiler optimizations may be correct and yet be insecure
Ensuring security of DSE through translation validation is difficult
A provably secure DSE transform based on taint propagation + domination
For several other optimizations, security does follow from correctness
(A compiler may generate candidate refinement witnesses, to be checked for correctness
[Namjoshi-Zuck, SAS 2013] and strictness.)
Important Open Questions
How to secure the SSA transformation without losing its advantages?
Witnesses for leakage preservation?
Avoiding timing-based leaks? E.g., by preserving constant-time implementations

14. A Secure DSE Procedure: Case 1
void foo () {
int x;
x = read_password ();
use (x);
x = 0; // Dead Store
x = 5; // Dead Store
return; }
The dead store is post-dominated by other stores to x.
Justification: any leak through x must arise from the dominating stores.
sat Case 1

15. A Secure DSE Procedure: Case 2
void foo () {
int x, y;
{x:U,y:U}
x = 0; // Dead Store
y = U:read_user_id ();
if (is_valid (y)) {
x = T:read_password ();
{x:T,y:U}
login (y,x);
x = 1; // Dead Store
} else {
printf ("Invalid ID"); }
return y;
Variable x is untainted before the dead store and is untainted at the program exit.
Justification: the taint proof is unchanged, so a leak cannot arise from x.
All other flows are preserved.
sat Case 2

16. A Secure DSE Procedure: Case 3
void foo () {
int x, y;
{x:U,y:U}
y = T:credit_card_no ();
{x:U,y:T}
x = y;
if (y > 0) {
use(x); }
{x:T,y:T}
x = 0; // Dead Store
x = last_4_digits (y); // Dead Store
y = 0; // Dead Store
{x:T,y:U}
return;
Variable x is untainted before the dead store, other stores to x are unreachable, and this store post-dominates the entry node.
Justification: the taint proof is unchanged, variable x is unmodified, so a leak cannot arise from x.
All other flows are preserved.
sat Case 1
sat Case 3

17. Acknowledgement
This work was supported, in part, by DARPA under agreement number FA C The U.S. Government is authorized to reproduce and distribute reprints for Governmental purposes notwithstanding any copyright notation thereon. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of DARPA or the U.S.