Untrustworthiness and ProtectionBuffer Overflow AttacksSlide 3Buffer Overflow Attacks (contd)StackGuardStackGuard (contd)StackGuard - Detecting RA Change Before ReturnSlide 8StackGuard - Preventing RA Changes With MemGuardSlide 10Automated Detection of Buffer Overrun VulnerabilitiesSlide 12Slide 13Slide 14Slide 15Slide 16Slide 17Slide 18Slide 19Rational PurifyPurify - Detecting Memory Access ErrorsPurify - Catching Array Bounds ViolationsPurify - Object Code InsertionType-Safe Languages - JavaJava SecurityThe Java SandboxAnatomy of a Java ApplicationJava Language SecurityRulesEnforcement of RulesEnforcement of Rules (contd)The Class LoaderClass LoaderSecurity ManagerAccess ControllerSummaryUntrustworthiness and ProtectionComputer Systems Security and Information Survivability- Presented by Deepak KumarBuffer Overflow Attacks•Internet Worm of November 1988.•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.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.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).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 AttackStackGuard (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 AddressStackGuard - 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.StackGuard - Detecting RA Change Before Return•StackGuard implementation - simple patch to gcc 2.7.2.2.•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.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.StackGuard•MemGuard used to protect an RA when a function is called, & un-protect the RA when the function returns.•Adaptive Defense StrategiesFunction Prologue Code: Protecting the Return Address With MemGuardAutomated 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.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.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.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].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 ≤ vAutomated Detection of Buffer Overrun VulnerabilitiesModeling the effects of string operations: some examples.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.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.Automated Detection of Buffer Overrun Vulnerabilities•Early experience with prototype –Linux net tools–Sendmail 8.9.3–Sendmail 8.7.5•Performance–Sub-optimal but usable.–Scalable.•Limitation: Large number of false alarms due to imprecision in the range
View Full Document
Unlocking...