Language-based Security Jay LigattiUniversity of South Florida
Outline • Introduction to software security • Constructing secure languages • Typing rules • Execution rules • Type safety • Extensions • Summary
Software Security • How can we constrain the behavior of our software?
Software Security • How can we constrain the behavior of our software? • In the presence of (malicious) attackers • E.g.: Log-in program must lock out users after three failed attempts
Software Security • How can we constrain the behavior of our software? • In the presence of (malicious) attackers • E.g.: Log-in program must lock out users after three failed attempts • Even in the absence of attackers • E.g.: Email program must not send invitations to my drunken myspace page to my professors (a privacy constraint)
Software Security • Obtaining these constraints requires first obtaining a more common constraint:Memory access control (MAC) • Data in memory can only be read and written in authorized ways
Software Security • Memory access control (MAC) • Data in memory can only be read and written in authorized ways • Type checking provides MAC • Strong checking controls all memory accesses • ML, Java, C#, Haskell, ... • Weak checking leaves holes open • C++, C, machine code, …
Type Checking • Well-typed programs provide proofs that programs are properly constrained (i.e., access memory correctly) • Type-checker verifies the proofs • Static analysis of code guarantees run-time constraints
Type Checking • A foundational security tool • Model of type checking is very general • Programs come with proofs of good behavior; anyone can verify the proofs • Underappreciated security tool • Java’s superior security over C/C++ is primarily due to type checking • But how does it work?
Outline • Introduction to software security • Constructing secure languages • Typing rules • Execution rules • Type safety • Extensions • Summary
A Simple Language • Consider a programming language with integers, booleans, and if-then-else’s • Exampleif (if true then false else true) then 6 else 8 • Evaluates to?
Typing Rules • For every expression, what’s its type? • true : bool [“true has type bool”] • false : bool • n : int (when n is any integer) • if e1 then e2 else e3 : ??
Typing Rules 4) if e1 then e2 else e3 : ?? Answer: Whatever types e2 and e3 have
Typing Rules 4) if e1 then e2 else e3 : ?? Answer: Whatever types e2 and e3 have if true then true else false : bool if true then 4 else 5 : int
Typing Rules 4) If (e1:bool and e2:T and e3:T)Then (if e1 then e2 else e3:T)
Typing Rules 4) If (e1:bool and e2:T and e3:T)Then (if e1 then e2 else e3:T) if (if true then false else true) then 6 else 8 : ??
Typing Rules 4) If (e1:bool and e2:T and e3:T)Then (if e1 then e2 else e3:T) if (if true then 6 else 8) then false else true : ??
Execution Rules • For every expression, how does it execute (i.e., “take a step”)? 0) true, false, and integers are final answers and do not execute further • if true then e1 else e2 => e1 • if false then e1 else e2 => e2 • (assuming e1 is neither true nor false)if e1 then e2 else e3 => ??
Execution Rules 3) (assuming e1 is neither true nor false)if e1 then e2 else e3 => ?? Answer: Execute e1 first if (if true then false else true) then 6 else 8 => if (false) then 6 else 8
Execution Rules 3) (assuming e1 is neither true nor false) If (e1=>e1’) Then (if e1 then e2 else e3 => if e1’ then e2 else e3)
Type Safety • With typing and execution rules defined, we can prove a type-safety theorem • Type safety: Well-typed programs will only obey the safeand expected rules of execution
Type Safety • Well-typed programs are constrained by the rules of execution • How have we constrained well-typed programs in our simple language?
Type Safety in Simple Language • Programs that pass our type checker will only branch on a true or a false value • Will never try to execute anything like:“if 5 then 6 else 8”Doing so would require an unsafeandunexpected execution rule
Type Safety in Simple Language • Programs that pass our type checker will only branch on a true or a false value • Memory access control (MAC) • A well-typed program will never read an int in memory when it should read a bool bool int
Type Safety in General • Well-typed programs will only read and write memory in “appropriate” ways • “Appropriate” means whatever is allowed by rules of execution
Outline • Introduction to software security • Constructing secure languages • Typing rules • Execution rules • Type safety • Extensions • Summary
Type Safety • Could add features to language and prove: • Only memory containing code get executed • Only in-bounds array elements get read/written • Only correctly typed pointers get dereferenced (e.g., return addresses really are return addresses) • Only public methods in objects can be executed by other objects
Type Safety • Could add features to language and prove: • Only memory containing code get executed • Only in-bounds array elements get read/written • Only correctly typed pointers get dereferenced (e.g., return addresses really are return addresses) • Only public methods in objects can be executed by other objects Memory access is constrained by execution rules
Run-time-checks Extension • Type safety provides a foundation for higher-level constraints • Can add run-time checks to constrain software further • E.g., to lock out users after failed logins, or to refuse to email myspace invitations to professors • Type safety ensures that run-time checks always work correctly (cannot be attacked successfully)
Outline • Introduction to software security • Constructing secure languages • Typing rules • Execution rules • Type safety • Extensions • Summary
Summary • Well-typed programs have constrained run-time behaviors • Only execute according to safe and expected rules => Will never access memory inappropriately • Programming in strongly typed languages like ML and Java is a good basis for writing secure code
Thanks Questions?
