preventing software vulnerabilities by static verification and run time checking

1KATHOLIEKEUNIVERSITEITLEUVEN

Secure Software - (C) 2002-2005 F. Piessens

Preventing Software Vulnerabilities by Static Verification and Run Time

Checking

Frank PiessensDept of Computer Science

K.U.Leuven

Secure Software - (C) 2002-2005 F. Piessens 2KATHOLIEKEUNIVERSITEITLEUVEN

Introduction

• How do you decrease the number of vulnerabilities in your code?• Today often realized by overloading the poor developer with

guidelines, principles, checklists, best practices,…


Introduction

• Key challenge: how can we automate the prevention of vulnerabilities or their exploitation?

• A vulnerability is essentially a bug– Hence, a violation of some (implicit or explicit) specification

• Interesting research questions:– What are these security-specific (partial) specifications?

• If we can make them explicit, we might be able to prevent or detect vulnerabilities automatically

– Can we infer them?– Can we use general-purpose specification/verification toolsets

to check them? (Spec#, JML tool suite, …)


Introduction

• Let’s look at some vulnerabilities from the OWASP Top Ten, and see what specification they violate:– Memory-management related bugs e.g. buffer overflow– Concurrency-management related bugs e.g race condition– I/O-management related bugs

• E.g. SQL injection• E.g. Application protocol checking

– Security vulnerabilities that arise because consistent integration of security technologies in an application is hard

• E.g. Incomplete access mediation


Introduction

• Goal of this talk: “teasers” for some of the research tracks in this area:– Safe concurrency in Spec#– Run-time application protocol checking for distributed

applications– …

• (We’ll see how far we get)


Overview

• Introduction• Safe concurrency in Spec#• Run-time application protocol checking for

distributed applications• Conclusions


Safe concurrency in SpeC# [Bart Jacobs]

• Joint work with MSR Redmond: Rustan Leino and Wolfram Schulte

• Problem: example in C#class Account { int balance; }Account act = …;int b0 = act.balance;act.balance += 50;int b1 = act.balance;

b1 == b0 + 50? Not necessarily!

lock (act) { b0 = act.balance; act.balance += 50; b1 = act.balance;}

b1 == b0 + 50? Not necessarily!


Race conditions as vulnerabilitiesvoid SomeSecureFunction() { if(SomeDemandPasses()) { fCallersOk = true; DoOtherWork(); fCallersOk = false(); }}

void DoOtherWork() { if( fCallersOK ) { DoSomethingTrusted(); } else { DemandSomething(); DoSomethingTrusted(); }}

Caching a security check

Can give another thread access

(Example from msdn library)


Observations

• C# offers synchronization primitives, but their correct use is not enforced

• Spec#’s primitives are very similar, but their correct use is enforced

acquire act;int b0 = act.balance;act.balance += 50;int b1 = act.balance;release act;

b1 == b0 + 50? Always!


Spec#’s ownership system

• Spec# structures the heap as a forest of objects ordered in an ownership hierarchy– Think of the owned sub tree as the component objects of the

root– Rep field modifier tags owned objects

• Spec# distinguishes “packed” and “unpacked” objects– Only unpacked objects can be modified– Upon packing, it is checked if the ownership ordering remains

a forest– Only root-objects can be unpacked, causing the root object to

lose ownership of its components


Illustrating pack and unpack

a

cb

x y

pack a

unpack a

a

cbx y

a

b

Unpacked object

Packed object, with ownership domain

xRep field reference

HEAP HEAP

Class A { rep B x; rep C y;}


Achieving safety

• Basic idea:– Extend ownership to threads– Writing to the fields of an object is only allowed by the owning

thread– Thread ownership changes through

• Acquire o: threads can acquire an object o that is a root object in the ownership hierarchy

– As a consequence the thread gains exclusive access to the entire ownership domain

• Release o: threads can release a packed object that they own– As a consequence, the thread loses access to the entire ownership

domain


Example

Thread 1 class Agg { rep Rep f; }class Rep {}

Agg a = new Agg;Rep r = new Rep;pack r;a.f = r;pack a;release a;


Example

Thread 1

a

class Agg { rep Rep f; }class Rep {}



Example

Thread 1

a

r




Summary

• Spec# ensures field accesses are thread-local operations

• Supports aggregate objects• Object invariants are enforced [not discussed here]• Full dynamic enforcement• Sound thread-local static checking• More information on:

– http://research.microsoft.com/specsharp/ – Bart Jacobs et al. Safe concurrency for aggregate objects

with invariants, SEFM 2005


Overview




Problem Statement

• Correct (secure) functioning of a distributed application can depend on the client adhering to an (often implicit) protocol or workflow– Stateless session beans on the application server– Protocol coded in web tier or client tier

Web Client Web Server App Server DB

Client Intranet


Problem Statement

• Example: prototypical e-commerce application– Stateless service methods

– Expected client operation

Product lookupProduct(String key)void processPayment(String customer, int amount)void shipProducts(String customer, Basket b)int computePrice(Basket b)

1) lookup several products and possibly put in basket2) compute price of basket3) ask confirmation from the user4) process payment for computed amount5) Ship all products in basket


Problem Statement

• If client workflow is enforced through coding, there can be a substantial risk that workflow logic is changed or bypassed– Example: workflow is implemented in a web tier

• Can be bypassed through forceful browsing or parameter tampering

– Example: workflow is implemented in client tier• Can be bypassed through reverse engineering of, and

tampering with client-side components


Run-time verification

General approach:– Position a filter between the two components at the side of the

trusted component– Filter is programmed with a model program– If an observed application event does not correspond to a possible

action in the model program, defensive measures are taken• Abort session• Log event• …

App ServerClient Filter

Model program


Example Model Program

enum ShoppingState {ProductSelection, ReadyToPay, ReadyToShip, End};ShoppingState state = ShoppingState.ProductSelection;int topay = 0; Product product = null; public Product LookupProduct(String key) requires state == ShoppingState.ProductSelection; { return <call real product lookup here>; }

public int ComputePrice(Product p) requires state == ShoppingState.ProductSelection; { state = ShoppingState.ReadyToPay; topay = <call real price computation logic here> product = p; return topay; }

void ProcessPayment(int amount) requires state == ShoppingState.ReadyToPay; requires amount == topay; { state = ShoppingState.ReadyToShip; <call real process payment> }…

Client State

State Update

Action Precondition


(Part of) Corresponding Model Automaton

(graph generated with the Spec Explorer tool from Microsoft Research)


Deriving model programs from client code

• Writing the model programs can be labor-intensive• An implementation of a valid client is also a specification

of the protocol– But possibly an over-specification– Not immediately usable to program a filter

• Our approach– Compile a non-deterministic pseudo-code client program to a

model program– Possibly compact the generated model automaton through

state grouping


Example pseudo client code

Product p; bool buy;String key; int price;

key = choose String;p = lookupProduct(key);price = computePrice(p);buy = choose bool;if (buy) { processPayment("XYZ",price); shipProducts("XYZ", p);}

Client Program State: values for vars + PC

All action sequences generated by this non-deterministicclient program are allowed


Construction of corresponding model program

• Client program state (cps):– Values for variables + Program Counter (PC)– Is stable if the PC points to a method call to the server

• Client State CS in model program– Set of possible stable client program states

• Precondition for a method call– There exists a cps in CS that is ready to perform that call

• Client State update after a call– Filter all cps that don’t have the observed call enabled– Reduce all remaining cps’s to a stable cps


Discussion

• Advantages:– Pseudo client programs are much easier to write,– … and can even be derived from existing client code by

replacing user input with choose statements– Pseudo client programs have a “default deny” semantics

• Disadvantages:– Pseudo client programs sometimes over constrain the

protocol– Performance of the filter is much worse

• But this could in principle be improved through more advanced compilation techniques


Overview




Conclusions

• Software security is a great opportunity for applications of formal methods and theory of programming

• Interesting developments in:– Programming concepts– Type systems– Code analysis tools– Runtime infrastructure

preventing software vulnerabilities by static verification and run time checking

Documents