Preventing software vulnerabilities by static verification and run time checking
This presentation is the property of its rightful owner.
Sponsored Links
1 / 33

Preventing Software Vulnerabilities by Static Verification and Run Time Checking PowerPoint PPT Presentation


  • 71 Views
  • Uploaded on
  • Presentation posted in: General

Preventing Software Vulnerabilities by Static Verification and Run Time Checking. Frank Piessens Dept of Computer Science K.U.Leuven. Introduction. How do you decrease the number of vulnerabilities in your code?

Download Presentation

Preventing Software Vulnerabilities by Static Verification and Run Time Checking

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Preventing software vulnerabilities by static verification and run time checking

Preventing Software Vulnerabilities by Static Verification and Run Time Checking

Frank Piessens

Dept of Computer Science

K.U.Leuven

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


Introduction

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,…

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


Introduction1

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, …)

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


Introduction2

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

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


Introduction3

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)

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


Overview

Overview

  • Introduction

  • Safe concurrency in Spec#

  • Run-time application protocol checking for distributed applications

  • Conclusions

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


Safe concurrency in spec bart jacobs

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!

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


Race conditions as vulnerabilities

Race conditions as vulnerabilities

void 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)

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


Observations

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!

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


Spec s ownership system

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

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


Illustrating pack and unpack

Illustrating pack and unpack

HEAP

HEAP

pack a

a

a

x

y

x

y

c

c

b

b

unpack a

a

Unpacked object

Class A {

rep B x;

rep C y;

}

b

Packed object, with ownership domain

x

Rep field reference

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


Achieving safety

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

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


Example

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;

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


Example1

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;

a

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


Example2

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;

a

r

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


Example3

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;

a

r

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


Example4

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;

a

r

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


Example5

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;

a

r

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


Example6

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;

a

r

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


Summary

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

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


Overview1

Overview

  • Introduction

  • Safe concurrency in Spec#

  • Run-time application protocol checking for distributed applications

  • Conclusions

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


Problem statement

Problem Statement

Client

Intranet

  • 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

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


Problem statement1

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 basket

2) compute price of basket

3) ask confirmation from the user

4) process payment for computed amount

5) Ship all products in basket

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


Problem statement2

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

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


Run time verification

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

Client

Filter

App Server

Model program

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


Example 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

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


Part of corresponding model automaton

(Part of) Corresponding Model Automaton

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

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


Deriving model programs from client code

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

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


Example pseudo client code

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-deterministic

client program are allowed

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


Construction of corresponding model program

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

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


Discussion

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

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


Overview2

Overview

  • Introduction

  • Safe concurrency in Spec#

  • Run-time application protocol checking for distributed applications

  • Conclusions

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


Conclusions

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

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


  • Login