Presentation is loading. Please wait.

Presentation is loading. Please wait.

Untrustworthiness and Protection Computer Systems Security and Information Survivability - Presented by Deepak Kumar.

Similar presentations


Presentation on theme: "Untrustworthiness and Protection Computer Systems Security and Information Survivability - Presented by Deepak Kumar."— Presentation transcript:

1 Untrustworthiness and Protection Computer Systems Security and Information Survivability - Presented by Deepak Kumar

2 Buffer Overflow Attacks Internet Worm of November Collected host, network, and user information. Then broke into other machines using flaws present in those systems’ software. Flaws: –fingerd and gets; no bounds checking. scanf/fscanf/sscanf, strcat/strcpy, sprintf –sendmail - DEBUG command exploited.

3 Buffer Overflow Attacks Exploit a lack of bounds checking on the size of input being stored in a buffer array. Attacker can make arbitrary changes to program state stored adjacent to the array. Commonly found in C programs. Why? –C lacks array bounds checking. –C programmers avoid error checking for performance reasons.

4 Buffer Overflow Attacks (contd) Most common data structure – the stack – “stack smashing attack”. 2 mutually dependent goals: –Inject Attack Code (attacker provides executable input string). –Change the Return Address (Buffer overflow changes the RA to point to the attack code). Which programs are attacked? –Usually, privileged daemons (i.e., under root).

5 StackGuard a compiler extension that enhances executable code produced by the compiler. detects and thwarts buffer-overflow attacks against the stack. transparent to the normal function of programs. Stack Smashing Buffer Overflow Attack

6 StackGuard (contd) Prevents changes to active RAs in 2 ways: 1.By detecting change of the RA before the function returns. (more efficient and portable). 2.By completely preventing the write to the RA (more secure). Canary Word Next to Return Address

7 StackGuard - Detecting RA Change Before Return Detection done before a function returns. A canary word placed next to the RA on the stack. When function returns, it first checks to see that the canary word is intact before jumping to the RA pointed word. Key: RA is unaltered iff the canary word is unaltered. (How?) – true for buffer overflow attacks.

8 StackGuard - Detecting RA Change Before Return StackGuard implementation - simple patch to gcc gcc function_prologue and function_epilogue functions - altered to emit code to place and check canary words. Problem: Attackers can develop buffer overflows insensitive to StackGuard. Solution: Randomize the Canary.

9 StackGuard - Preventing RA Changes With MemGuard “Quasi-invariants” – optimistic specializations. Treat return addresses on the stack as quasi- invariant during the activation lifetime of the function. RA  read-only (invariant)  prevents effective buffer overflow against the stack. MemGuard – tool to help debug optimistic specializations functions  locates code statements that change quasi-invariant values.

10 StackGuard MemGuard  used to protect an RA when a function is called, & un-protect the RA when the function returns. Adaptive Defense Strategies Function Prologue Code: Protecting the Return Address With MemGuard

11 Automated Detection of Buffer Overrun Vulnerabilities Involves a synthesis of ideas from program analysis, theory, and systems security. Main Idea: to apply standard static analysis techniques. Formulate the buffer overrun detection problem as an integer constraint problem. Use some simple graph theoretic techniques to construct an efficient algorithm for solving the integer constraints.

12 Automated Detection of Buffer Overrun Vulnerabilities Security knowledge  used to formulate heuristics  capture the class of security- relevant bugs that tend to occur in real programs. Aim for scalability at the cost of precision. Reason: to analyze large programs – like sendmail. Result: Some false negatives and false positives.

13 Automated Detection of Buffer Overrun Vulnerabilities 2 fundamental new insights: –Treat C strings as an abstract data type. –Model buffers as pairs of integer ranges (allocated size, currently used length). A secondary contribution: scalable and very fast integer range analysis – can handle cyclic data dependencies without loss of precision by invoking a fixpoint theorem. The architecture of the buffer overflow detection prototype.

14 Automated Detection of Buffer Overrun Vulnerabilities Z = Set of integers. Z ∞ = Z U {-∞, +∞}. A Range is a set R ≤ Z ∞ of the form [m, n] = {i € Z ∞ : m ≤ i ≤ n}. S is a subset of Z ∞, inf S and sup S. inf[m, n] = m; sup[m, n] = n. Range Closure of S ≤ Z ∞, is the minimal range R containing S, i.e., R = [inf S, sup S].

15 Automated Detection of Buffer Overrun Vulnerabilities Integer Range Expression e: e ::= v | n | n x v | e + e | e – e | max(e,…,e) | min(e,…,e) where n € Z and v € Vars, a set of range variables. Integer Range Constraint e ≤ v

16 Automated Detection of Buffer Overrun Vulnerabilities Modeling the effects of string operations: some examples.

17 Automated Detection of Buffer Overrun Vulnerabilities Theorem: Every constraint system has a unique least solution. Constraint generation: –proceeds by traversing the parse tree for the input C source code –generating a system of integer range constraints. –With each integer program variable v, a range variable is associated.

18 Automated Detection of Buffer Overrun Vulnerabilities alloc(s), len(s). Safety property to be verified: len(s) ≤ alloc(s) Flow-insensitive analysis. Model function calls monomorphically. Problems due to pointer aliasing. Theorem: We can solve the constraint subsystem associated with a cycle in linear time.

19 Automated Detection of Buffer Overrun Vulnerabilities Early experience with prototype –Linux net tools –Sendmail –Sendmail Performance –Sub-optimal but usable. –Scalable. Limitation: Large number of false alarms due to imprecision in the range analysis.

20 Rational Purify A tool that developers and testers are using to find memory leaks and access errors. Detects the following at the point of occurrence: –reads or writes to freed memory. –reads or writes beyond an array boundary. –reads from uninitialized memory. Upon demand, employs a garbage detector to find and identify existing memory leaks. Purify finds run-time-detectable errors.

21 Purify - Detecting Memory Access Errors Purify "traps" every memory access a program makes. Maintains and checks a state code for each byte of memory. Accesses inconsistent with the current state cause a diagnostic message to be printed. The function CATCH_ME is called (breakpoint). Memory State Transition Diagram

22 Purify - Catching Array Bounds Violations To catch array bounds violations, Purify allocates a small "red-zone" at the beginning and end of each block returned by malloc. The bytes in the red-zone  recorded as unallocated. If a program accesses these bytes, Purify signals an array bounds error.

23 Purify - Object Code Insertion Uses object code insertion to augment a program with checking logic. Done before or after linking. Advantages: –setup performance. –convenience. –multi-language support. –completeness. Example Make

24 Type-Safe Languages - Java Buffer Overrun problem – due to lack of type safety in C. Type-safety is one of the foundations of the Java security model. Java Security Goals –programs should be: –Safe from malevolent programs –Non-intrusive –Authenticated

25 Java Security –Encrypted –Audited –Well-defined –Verified –Well-behaved –C2 or B1 certified Java SandBox - provide an environment on the computer where the program can play but confined within certain bounds.

26 The Java Sandbox Minimal Sandbox - Access to CPU, screen, keyboard, and mouse, and to its own memory. Default Sandbox - Access to CPU and its own memory as well as access to the web server from which it was loaded. Access to CPU, its memory, its web server, and to a set of program-specific resources. Open Sandbox – access to all resources.

27 Anatomy of a Java Application Bytecode verifier Class loader Access controller Security manager Security package Key database

28 Java Language Security Java Language Security Constructs –every primitive data element has an access level associated with it which can be: Private Default (or package) Protected Public Credit Card example - and

29 Rules Access methods are strictly adhered to. Programs cannot access arbitrary memory locations. Entities that are declared as final must not be changed. Variables may not be used before they are initialized. Array bounds must be checked on all array accesses. Objects cannot be arbitrarily cast into other objects.

30 Enforcement of Rules Compiler Enforcement The Bytecode Verifier –Class file has correct format. –Final classes not subclassed, and final methods not overridden. –Every class has a single superclass.

31 Enforcement of Rules (contd) –No illegal data conversion of primitive data types (e.g., int to Object). –No illegal data conversion of objects occurs. –no operand stack overflows or underflows. Runtime Enforcement –Array bounds checking –Object casting

32 The Class Loader Initially, only the class loader knows certain information about classes that have been loaded into the virtual machine. Only the class loader knows where a particular class originated. Only the class loader knows whether or not a particular class was signed.

33 Class Loader Class Loaders and Security Enforcement Class Loaders and Namespaces Anatomy of a Class Loader –The Internal Class Loader –The Applet Class Loader –The RMI Class Loader –The Secure Class Loader –The URL Class Loader

34 Security Manager Ultimately responsible for determining most of the parameters of the Java sandbox. Ultimately determines whether operations should be permitted or rejected. Trusted and Untrusted Classes. An untrusted class cannot directly connect to the database server

35 Access Controller Decides whether access to a critical system resource should be permitted or denied. The CodeSource Class. Permissions. Protection Domains. AccessController Class. Guarded Objects. Coordination of the security manager and the access controller.

36 Summary Buffer Overflow attacks due to memory vulnerabilities in C. Methods to prevent buffer overflow attacks: –StackGuard. –Static Analysis. –Array Bounds Check (Rational Purify). –TypeSafe Language – Java. Java Security.


Download ppt "Untrustworthiness and Protection Computer Systems Security and Information Survivability - Presented by Deepak Kumar."

Similar presentations


Ads by Google