Introduction to Language Based Security

Transcription

1 Introduction to Language Based Security Ana Matos and Miguel Correia

2 who ARE YOU? Ana Almeida Matos Office: Tagus, 2N3-11. Contact hours: See web page or send . Research: Language Based Security, Information Flow, Type systems...

3 Class Outline Language Based Security - what and why Program Analysis for Security - an overview Semantics of Programming Languages - basics

4 Topics of the course part I Principles of Computer Security Overview and Protection Software vulnerabilities Development of secure software Control of execution environment

5 Questions raised in this course Which are the most common software security vulnerabilities? How can we secure the execution environment? What are the fundamental problems behind the vulnerabilities? How can we design techniques and tools to prevent or fix them?

6 Language-Based Security techniques based on programming language theory and implementation, including semantics, types, optimization and verification, brought to bear on the security question Schneider et. al, 2000 "Laguage-based security - A research manifesto for a Dagstuhl Seminar,

7 Language-Based Security In sum: Attacks: Application level Tools: Programming language analysis techniques.

8 Programming language techniques For design, implementation, analysis, characterization, classification of programming languages and their individual features. Examples: compilation, monitoring, type checking and other program analysis, program rewriting... Offer appropriate abstractions to deal with software security issues.

9 Security by design Applications are implemented in programming languages systems are modeled at different levels of abstraction (using different languages) security policies can be expressed and analyzed at each of these levels security-by-design: using language-based analysis techniques to provably enforce specified security properties offers strong guarantees Some examples...

10 Buffer overflows... Buffer-Overflow Protection: The Theory by Krerk Piromsopa and Richard J. Enbody (2006) Abstract. We propose a framework for protecting against buffer overflow attacks the oldest and most pervasive attack technique. The malicious nature of buffer-overflow attacks is the use of external data (input) as addresses (or control data). With this observation, we establish a sufficient condition for preventing buffer-overflow attacks and prove that it creates a secure system with respect to buffer-overflow attacks. The underlying concept is that input is untrustworthy, and should not be used as addresses (return addresses and function pointers.). If input can be identified, buffer-overflow attacks can be caught. We used this framework to create an effective, hardware, buffer-overflow prevention tool.

11 Buffer overflows... Code-Pointer Integrity by Volodymyr Kuznetsov, Laszló Szekerés, Mathias Payer, George Candea, R. Sekar, Dawn Song (2014) Abstract. Systems code is often written in low-level languages like C/C+ +, which offer many benefits but also delegate memory management to programmers. This invites memory safety bugs that attackers can exploit to divert control flow and compromise the system. Deployed defense mechanisms (e.g., ASLR, DEP) are incomplete, and stronger defense mechanisms (e.g., CFI) often have high overhead and limited guarantees [19, 15, 9]. We introduce code-pointer integrity (CPI), a new design point that guarantees the integrity of all code pointers in a program (e.g., function pointers, saved return addresses) and thereby prevents all control-flow hijack attacks, including return-oriented programming. (...)

12 Format strings... Detecting Format String Vulnerabilities with Type Qualifiers Flow Abstraction by Umesh Shankar Kunal Talwar Jeffrey S. Foster David Wagner (2001) Abstract. We present a new system for automatically detecting format string security vulnerabilities in C programs using a constraint-based type-inference engine. We describe new techniques for presenting the results of such an analysis to the user in a form that makes bugs easier to find and to fix. The system has been implemented and tested on several real-world software packages. Our tests show that the system is very effective, detecting several bugs previously unknown to the authors and exhibiting a low rate of false positives in almost all cases. Many of our techniques are applicable to additional classes of security vulnerabilities, as well as other type- and constraint based systems.

13 Data races... Maximal Sound Predictive Race Detection with Control Flow Abstraction by Jeff Huang Patrick O Neil Meredith Grigore Rosu (2014) Abstract. Despite the numerous static and dynamic program analysis techniques in the literature, data races remain one of the most common bugs in modern concurrent software. Further, the techniques that do exist either have limited detection capability or are unsound, meaning that they report false positives. We present a sound race detection technique that achieves a provably higher detection capability than existing sound techniques. (...) Moreover, we formally prove that our formulation achieves the maximal possible detection capability (...). We demonstrate via extensive experimentation that our technique detects more races than the other state-of-the-art sound race detection techniques, and that it is scalable to executions of real world concurrent applications with tens of millions of critical events. These experiments also revealed several previously unknown races in real systems (e.g., Eclipse) that have been confirmed or fixed by the developers. (...)

14 Code-injection... Automated Code Injection Prevention for Web Applications by Zhengqin Luo, Tamara Rezk, and Manuel Serrano (2011) Abstract. We propose a new technique based on multitier compilation for preventing code injection in web applications. It consists in adding an extra stage to the client code generator which compares the dynamically generated code with the specification obtained from the syntax of the source program. No intervention from the programmer is needed. No plugin or modification of the web browser is required. The soundness and validity of the approach are proved formally by showing that the client compiler can be fully abstract. The practical interest of the approach is proved by showing the actual implementation in the Hop environment.

15 Topics of the course part II Language Based Security Security monitors Program analysis for security - overview Information flow security Security type systems Security-preserving compilation

16 Class Outline Language Based Security - what and why Program Analysis for Security - an overview Semantics of Programming Languages - basics

17 Program Analysis (for Security) the process of automatically analyzing the behavior of computer programs regarding a (security) specification. Segurança no Software, Miguel Correia and Paulo Sousa, 2010 (Chapter 11). Static Analysis for Security, Brian Chess and Gary McGraw, 2004.

18 So why do developers keep making the same mistakes? Instead of relying on programmers memories, we should strive to produce tools that codify what is known about common security vulnerabilities and integrate it directly into the development process. D. Evans e D. Larochelle, 2002

19 What is the right question? Is this program secure? Is this program secure against this threat? We need to be precise. Does this program meet security requirement P? Does this program meet security requirement P given attacker model A? When do programs written in this language meet security requirement P given attacker model A?

20 Aims of Program Analysis Optimization - about performance, to compute in a more efficient way. Improve running time, decrease space requirements, decrease power consumption Correctness - about assurance, to compute as intended. Detecting/correcting bugs, security vulnerabilities Guaranteeing security properties

21 Security properties correctness - intended behavior robustness - doesn t crash or hang safety - doesn t run into bad states (ex: access control is violated) liveness - good things happen (ex: you get a response)...

22 Precision of a mechanism Given a computer system and a security policy, how precisely can we enforce it? If S is the set of secure states, and a mechanism restricts the system to a set of states R: Sound mechanism: R S Precise mechanism: R = S Complete mechanism: R S

23 Question on limitations Given a computer program and a security policy, can we determine automatically whether or not it is secure? In other words: Is the security problem decidable? Decidable problem - A decision problem that can be solved by an algorithm (that halts on all inputs). The halting problem (termination of a program written in a Turing-expressive language) is undecidable.

24 Limits to precision Security policies typically talk about behavior of a system, and are often undecidable. Who is allowed to do something?, What is allowed to be done?... Mechanisms typically provide automatic ways of restricting the behavior of the system, and are often decidable. How can we enforce these rules? In such (most) cases... a mechanism cannot be precise!

25 Usefulness of automatic analysis In spite of these known limits, automatic analysis can still be useful: Unsound mechanisms might accept insecure programs (false negatives). But, they can still filter out a number of vulnerabilities. Incomplete mechanisms might reject secure programs (false positives). But, they can give strong guarantees about the absence of vulnerabilities.

26 Advantages of automatic analysis Verifies code thoroughly and consistently, without bias or errors introduced by human auditors. Time efficiency. Can analyze binary or intermediate code. Can be designed to give strong guarantees.

27 Limitations of automatic analysis Limited precision We have seen that a decidable analysis cannot be precise: it is either unsound (too permissive) or incomplete (too conservative). Limited scope (as strong as it s assumptions) Designed to look for a finite set of problems - it is not possible to test all conditions. Limited understanding Manual work is still needed, at different degrees.

28 Timing of program analysis Static analysis - before program execution. Dynamic analysis - during program execution, or posteriorly based on collected data. or... Hybrid - combination of both. Use output of one analysis as input to another (static to dynamic and dynamic to static).

29 Dynamic Analysis techniques Examples Testing Dynamic type checking (ex: Perl, Python, JavaScript...) Monitoring (future class)...

30 Static Analysis techniques Examples Control-flow analysis Model checking Program Verification... Abstract interpretation Type and effect systems

31 Precision if <input> then <fine> else <vulnerability> Static analysis Requires an approximation of actual input data. Conservative in accounting for all possibilities. Dynamic analysis Can take advantage of runtime knowledge in order to increase precision. Restricted to a subset of possible executions. Results may not generalize to all executions.

32 Precision if <secret_input> then <output 0> else <output 1> Static analysis Can consider all possible input data by abstraction. Dynamic analysis Analyzing a subset of possible executions can be theoretically insufficient for asserting properties that involve sets of traces (ex: information flow).

33 Precision Hybrid analysis: Dynamic to Static Example: Profile directed compilation - collects useful information from one program execution to assist compilation and improve program optimizations Hybrid analysis: Static to Dynamic Increase scope by combining with prior static analysis.

34 Time cost Static analysis Static time overhead. Slow to analyze large models of input data Dynamic analysis - May impose a cost on efficiency, due to runtime checks.

35 Time cost Hybrid analysis: Static to Dynamic Optimize execution time checks Example: type checks my be guaranteed at compilation time Indicate suspicious code to test more thoroughly Hybrid analysis: Dynamic to Static Apply more complex static analysis to properties observed at run time

36 Development Static analysis Can find problems early in the development cycle, even before the code is run for the first time. Reveals the root of a security problem, not its symptoms (as opposed to testing). Dynamic analysis Can find problems that are left aside by the static analysis. Requires a choice of test runs and an infrastructure for running them.

37 Static Analysis Tools -- an overview

38 Static analysis and compilation are closely related Analyze to compile, compile to analyze Compilers always include some form of program analysis, as certain errors impede compilation. Standard analysis performed by compilers can be used for additional security checks and transformations. Compilers are also programs that can be analyzed: Does the compiler preserve the security properties that are checked on the source code? (Another class)

39 Standard compilation stages source code lexical analyzer (scanner) breaks source code into tokens preprocessor semantic analyzer (parser) builds a syntax tree intermediate code generator optimizer target code generator target code front end back end

40 A generic static analysis tool

41 Build model Do lexical analysis and parsing Build an abstract syntax tree (AST) Generate simultaneously a table of symbols AST can be used for doing type checking Use the AST to build a control flow graph and a call graph... CFG can be used for doing control-flow analysis / dataflow analysis

42 Specify property What to verify can be stated as assertions or rules Ex: strcpy(dest, src) assert(size(dest) > size(src)) Ex: no tainted data can be assigned to an untainted attribute

43 Complexity of tools String matcher - runs directly over source code. Lexical analyzer - runs over the tokens generated by the scanner. Does not confuse a variable getshow with a call to gets (different tokens). Semantic analyzer - runs over the syntax tree generated by the parser. Does not confuse a variable gets with a call to function gets (different meaning).

44 String matchers Simple tools like grep and findstr can do a very basic form of analysis. grep gets *.c and grep strcpy *.c Limitations The user has to know which functions are dangerous The user has to do all the greps Does not distinguish between actual dangerous functions and instances of these strings that are not calls int main { int strcpy; return 0; } // var. strcpy

45 Lexical analyzers Look for dangerous library/system calls Detect calls which are always dangerous (for ex: gets...). Attribute danger levels to the potential vulnerabilities Main components Database of vulnerable system/library calls Code preprocessor (to get what will be really compiled) Lexical analyzer (to read functions names) Examples: RATS, Flawfinder, ITS4

46 Example output (Flawfinder)

47 Example database (Flawfinder)

48 Semantic analyzers Control flow analysis Data flow analysis Type checking

49 Control-flow analysis All the possible control flows of a program can be represented by a control flow graph (CFG). Control-flow analysis performs checks based on the possible control paths of a program. Essential for many compiler optimizations. Can be used to statically verify properties that depend on the sequencing of instructions. Example: PREfix.

50 PREfix C/C++ Detects problems like: invalid pointer references, use of uninitialized memory, improper operations on resources like files (e.g., trying to close a closed file) Individual functions are tested and errors reported Starting in the leafs Determine the control flow paths and simulate a representative set (configurable)

51 Example: memory allocation Simulating a path: traverses the abstract syntax tree of a function evaluating the relevant instructions In the end, the state of the memory is summarized

52

53

54 Scope of the analysis Local analysis: analyzes one function at a time. Module-level analysis: analyzes one class / compilation unit at a time, based on the models generated by local analysis. Considers the relations among functions. Global analysis: analyzes the whole program, given the previous analysis of functions and modules. Considers the relations among modules.

55 Data-flow analysis A technique for gathering information about the possible set of values calculated at various points of a program. Can determine where an actual value assigned to a variable might propagate. Often used by compilers for optimization (ex: reaching definitions) One application of data-flow analysis for security is taint analysis. Ex: FlowDroid (a static taint analysis tool for Android applications)

56 Taint analysis with CQUAL Uses type qualifiers to perform taint analysis in C programs Requires someone to annotate functions as either returning data tainted or requiring untainted data Type qualifiers: $tainted, $untainted Then uses type inference rules (along with preannotated system libraries) to detect vulnerabilities e.g., format string vulnerabilities, user-space/ kernel-space trust errors; XSS

57 Example: detection of a format string vulnerability getenv returns a tainted string printf requires an untainted format string annotations

58 Type checking Type systems associate types to selected programs that fulfill certain requirements (eg. are considered correct with respect to a property). Type checking - to verify whether a program is accepted by the type system. Type inference - to infer the type that allows a type system to accept a program.

59 Type checking in programming languages The notion of type is central to programming Types are used in programming to limit how programming objects (variables, functions...) are used, for example: Integers can t be assigned to string variables Functions are called with the right number and type of arguments. Type checking is done by compilers and interpreters

60 Type checking and security Type systems of programming languages are important but most are limited for security Some integer manipulation vulnerabilities that are found by type checking: Signedness integer with signal is attributed to an unsigned (or vice-versa) Truncation integer represented with N bits is assigned to an integer variable with less than N bits (e.g., int to short)

61 Static vs. dynamic typing Statically typed languages performed in run-time performed in compile time Ex: C(++), Java, Haskell, Pascal, ML... Dynamically typed languages Ex: PHP, JavaScript, Tcl, Prolog, Python...

62 Security Type Systems There is a range of security-oriented type systems developed by the research community. Some are integrated in full-fledged programming languages. Ex: Jif Java extension to enforce information flow policies by imposing confidentiality and integrity constraints.

63 Human intervention trade-off Verification of complex properties can be achieved with more human intervention: Model checking -- Checks a model of a program, or the code itself. Enables to check its design. Program Verification -- Formally proves a property about a program.

64 Model checking Given a model of a system, check automatically whether this model satisfies a certain property. Application example: security protocols. A model is a description of the system (program, protocol, hardware...) based on states and possible transitions in between them. Can check reachability of states bad states cannot reached - safety properties good states will be reached - liveness properties

65 Limitations of model checking Defining the model involves some manual work. State space explosion (although there are techniques for reducing the number of states). As precise as the model (proving that a model is correct does not mean that the implementation is correct)

66 Model checking C programs Tools: CBMC, MOPS, F-SOFT, BLAST,... Some of these tools put constraints on the programs, check only safety properties, perform only bounded model checking, work over an abstraction (possible imprecision), but they can be used for checking security properties (including buffer overflow, race condition,...).

67 Program verification How to formally verify that a program satisfies a given (security) property? Use a program logic, which consists of a specification language for expressing properties of a program an associated logic for (dis)proving that programs meet specifications ex: Hoare logic, weakest pre-condition calculus

68 Limitations of Program verification Requires high expertise for describing the model and properties to be verified Involves some manual work.

69 Class Outline Language Based Security - what and why Program Analysis for Security - an overview Semantics of Programming Languages - basics

70 (A bit of) Programming language semantics specification of the meaning of programs of that programming language Semantics with Applications: A Formal Introduction, H. Nielson, F. Nielson, 1992 (Chapter 1 -- Section 2.1.).

71 Formal semantics Why do it formally? For clarity (prevent ambiguities in language specification) For correctness (the basis for implementation, analysis and verification) Why do it in this course? Security properties are often semantic.

72 How to do it? Operational semantics - describe how the effect of a computation is produced when executed on a machine. Denotational semantics - define what is the effect of a computation, as a mathematical object. Axiomatic semantics - assert properties of the effect of a computation.

73 A WHILE language The next slides present a WHILE language as defined in the tutorial G. Barthe et al. (2011). The language is a (simpler) variation of the one in Nielson & Nielson (1999).(*) (*) Differences are: Constants are simply integers (and not numerals). Arithmetic expressions use operations that are used directly in the semantics. Boolean expressions are reduced to comparisons between arithmetic expressions (tests).

74 Syntax of WHILE Syntactic categories: n Num - numerals x Var - variables a Aexp - arithmetic expressions t Bexp - tests S Stm - statements Grammar (BNF notation): basic elements + composite elements op ::= + - / cmp ::= < = > n ::= 0 1 n 0 n 1 a ::= n x a1 op a2 t ::= a1 cmp a2 S ::= x:=a skip S1 ; S2 if t then S else S while t do S

75 Syntax of WHILE Syntactic categories: c Z - constants (integers) x Var - variables a Aexp - arithmetic expressions t Bexp - tests S Stm - statements Grammar (BNF notation): (Abuse: to simplify, we will specify constants directly as integers.) op ::= + - / cmp ::= < = > a ::= c x a1 op a2 t ::= a1 cmp a2 S ::= x:=a skip S1 ; S2 if t then S else S while t do S

76 Abstract syntax Tree representation Linear representation Example: z:=x ; x:=y ; y:=z we will write either (z:=x ; x:=y) ; y:=z or z:=x ; (x:=y ; y:=z)

77 State function ρ ρ - memory or state function that maps variables to integers Example: ρ(x) = 1, ρ(y) = 42...

78 Semantics functions to define next (N - function that maps numerals to integers) A - function that maps pairs of arithmetic expression and state to integers B - function that maps pairs of test and state, to booleans S - partial function that maps pairs of statement and state to state.

79 A - function that maps pairs of arithmetic expression and state, to integers A[c]ρ = c op ::= + - / Semantics of arithmetic expressions: A A[x]ρ = ρ(x) Abuse: skipping the use of N to get value of numerals (cf. exercise) A[a1 op a2]ρ = A[a1]ρ op A[a2]ρ Abuse: syntactic representation of op equals its mathematical meaning.

80 Semantics of arithmetic expressions: A A - function that maps pairs of arithmetic expression and state, to integers A[c]ρ = c A[x]ρ = ρ(x) compositional definition: one semantic clause for each basic element and each composite element (in terms of immediate constituents) A[a1 op a2]ρ = A[a1]ρ op A[a2]ρ op ::= + - /

81 Semantics of boolean expressions: B B - function that maps pairs of test and state, to booleans (from the set {true, false}) B[a1 cmp a2]ρ = A[a1]ρ cmp A[a2]ρ Abuse: syntactic representation of cmp equals its mathematical meaning. cmp ::= < = >

82 Semantics of statements: S S - partial function that maps pairs (statement,state) to state. We will define it using a natural operational semantics, by means of big-step transitions: speaks about how the overall result of executions is obtained. S, ρ ρ When executing program S on memory ρ we obtain the new memory ρ

83 We could also have used a structural operational semantics, by means of small-step transitions: speaks about how the individual steps of the computations take place. S, ρ S, ρ Performing one step of program S on memory ρ leavsthe continuation S and produces new memory ρ We will define a small step semantics for a bytecode language in a future class.

84 Big-step transitions Axioms - do not depend on any hypothesis in order to give the final result of the computation Skip: skip, ρ ρ Does nothing! Assignment: x:=a, ρ ρ[x A[a]ρ] Updates the value of x in ρ with the result of evaluating a { the update of state ρ is defined as: (ρ[y c])(x) = c, if x=y ρ(x), otherwise

85 Rules - the final result of the computation below the line, depends on the hypothesis above the line When the first program starting on ρ produces ρ... Sequential composition:... and the second program starting on ρ produces ρ... S1, ρ ρ ρ2, ρ ρ S1;S2, ρ ρ... then the entire sequential composition starting on ρ produces ρ.

86 Rules - the final result of the computation below the line, depends on the hypothesis above the line When t evaluates to true... Conditional test: S1, ρ ρ if t then S1 else S2, ρ ρ S2, ρ ρ if t then S1 else S2, ρ ρ... and the first branch starting on ρ produces ρ... if B[t]ρ = true then the conditional starting on ρ produces ρ. if B[t]ρ = false

87 Rules - the final result of the computation below the line, depend on the hypothesis above the line While loop: S,ρ ρ while t do S, ρ ρ if B[t]ρ = true... the body starting on ρ produces ρ... When t evaluates to true... while t do S, ρ ρ... and the continuation of the cycle on ρ produces ρ then the cycle on ρ produces ρ. while t do S, ρ ρ if B[t]ρ = false When t evaluates to false the cycle does nothing.

88 (All) Big-step axioms & rules Assignment: x:=a, ρ ρ[x A[a]ρ] Skip: skip, ρ ρ Sequential composition: S1, ρ ρ ρ2, ρ ρ S1;S2, ρ ρ Conditional test: S1, ρ ρ if B[t]ρ = true if t then S1 else S2, ρ ρ S2, ρ ρ if B[t]ρ = false if t then S1 else S2, ρ ρ While loop: S,ρ ρ while t do S, ρ ρ if B[t]ρ = true while t do S, ρ ρ while t do S, ρ ρ if B[t]ρ = false

89 Example - Evaluation Evaluate (z:=x ; x:=y) ; y:=z, starting from a state ρ0 that maps all variables except x and y to 0, and has ρ0(x) = 5 and ρ0(y) = 7. z:=x, ρ0 ρ1 x:=y, ρ1 ρ2 derivation tree (z:=x ; x:=y), ρ0 ρ2 y:=z, ρ2 ρ3 (z:=x ; x:=y) ; y:=z, ρ0 ρ3 ρ1 = ρ0[z 5] ρ2 = ρ1[x 7] ρ3 = ρ2[y 5]

90 Evaluation - derivation tree To evaluate a statement S, starting from a state ρ, a derivation tree must be constructed: 1. Construct the tree from root upwards. 2. Try to find an axiom or rule whose left side matches S, ρ and whose side conditions are satisfied. If it is an axiom - determine the final state and terminate. If it is a rule - try to construct the derivation tree for the premisses of the rule in order to determine the final state.

91 The semantic function S The meaning of statements is given as a (partial) function from the set of states to the set of states. { ρ if S, ρ ρ S[S]ρ= undefined, otherwise no meaning is given to non-terminating computations

92 Summarizing: Natural semantics (big-step transition system) Configurations: intermediate Statement S, state ρ terminal ρ Transitions: S, ρ ρ Rules: S1, ρ1 ρ1... Sn, ρn ρn if... S, ρ ρ

93 Conclusions We have defined formally the operational semantics for a simple language WHILE. The same can be done for any language in a similar manner (in future class, for a byte-code language.) This allows us to reason rigorously about the behavior of programs in the language. We will use it to formalize and prove security properties, which are often semantic.