Code for Security Somesh Jha University of Wisconsin (Mar 3, 2011) - - PowerPoint PPT Presentation

▶
code for security
SMART_READER_LITE
LIVE PREVIEW

Code for Security Somesh Jha University of Wisconsin (Mar 3, 2011) - - PowerPoint PPT Presentation

Jan 25, 2023 174 likes •757 views

Thoughts on Retrofitting Legacy Code for Security Somesh Jha University of Wisconsin (Mar 3, 2011) Science of Security, ITI (April 2, 2015) Kaminsky scores 23, No. 5 Wisconsin beats Illinois 68-49 Feb 15, 2015 Somesh Jha Retrofitting

slide-1
SLIDE 1

Thoughts on Retrofitting Legacy Code for Security

Somesh Jha University of Wisconsin

(Mar 3, 2011) Science of Security, ITI (April 2, 2015)

slide-2
SLIDE 2

Somesh Jha Retrofitting Legacy Code for Security 2

Kaminsky scores 23, No. 5 Wisconsin beats Illinois 68-49 Feb 15, 2015

slide-3
SLIDE 3

Somesh Jha Retrofitting Legacy Code for Security 3

slide-4
SLIDE 4

Threat Landscape: Summary of Symantec Threat Report 2014

slide-5
SLIDE 5

Key Findings

  • 91% increase in targeted attacks

campaigns in 2013

  • 62% increase in the number of breaches

in 2013

  • Over 552M identities were exposed via

breaches in 2013

  • 23 zero-day vulnerabilities discovered
  • 38% of mobile users have experienced

mobile cybercrime in past 12 months

Somesh Jha Retrofitting Legacy Code for Security 5

slide-6
SLIDE 6

Key Findings (Contd.)

  • Spam volume dropped to 66% of all email

traffic

  • 1 in 392 emails contain a phishing attacks
  • Web-based attacks are up 23%
  • 1 in 8 legitimate websites have a critical

vulnerability

Somesh Jha Retrofitting Legacy Code for Security 6

slide-7
SLIDE 7

What I feel like?

Somesh Jha Retrofitting Legacy Code for Security 7

slide-8
SLIDE 8

News is Grim

  • See talks at
  • DARPA Cyber Colloqium
  • http://www.darpa.mil/Cyber_Colloqium_Prese

ntations.aspx

  • What do we do?

Somesh Jha Retrofitting Legacy Code for Security 8

slide-9
SLIDE 9

Clean-slate Design

  • Rethink the entire system stack
  • Networks
  • NSF program
  • See http://cleanslate.stanford.edu
  • See DARPA Mission Resilient Clouds (MRC)

program

  • Hosts
  • DARPA CRASH program

Somesh Jha Retrofitting Legacy Code for Security 9

slide-10
SLIDE 10

Somesh Jha Retrofitting Legacy Code for Security 10

Some Interesting Systems

  • Operating systems with powerful capabilities
  • Asbestos, HiStar, Flume
  • Capsicum
  • ….
  • Virtual-machine based
  • Proxos
  • Overshadow
  • Possible to build applications with strong

guarantees

  • Web server: No information flow between threads

handling different requests

slide-11
SLIDE 11

Two Guiding Principles

  • Provide powerful primitives at lower levels

in the “system stack”

  • Example: HiStar (information flow labels at

the OS level)

  • Systems will be compromised, but limit the

damage

  • Example: Process can be compromised, but

sensitive data cannot be exfiltrated

Somesh Jha Retrofitting Legacy Code for Security 11

slide-12
SLIDE 12

Somesh Jha Retrofitting Legacy Code for Security 12

What happens to all the code?

  • Should we implement all the code from

scratch?

  • Can we help programmers adapt their code

for these new platforms?

  • Analogy
  • We have strong foundation
  • Can we build a strong house on top of it?
slide-13
SLIDE 13

Ideal Functionality

  • Input: functionality/security policy
  • Output: functional/secure code
  • Proving safety is “undecidable”
  • Rice’s theorem (proving any non-trivial

property is undecidable)

  • I think
  • Synthesis is “relatively hard”
  • Even if provided with an oracle to prove safety

Somesh Jha Retrofitting Legacy Code for Security 13

slide-14
SLIDE 14

Somesh Jha Retrofitting Legacy Code for Security 14

Retrofitting legacy code

Need systematic techniques to retrofit legacy code for security

Legacy code Retrofitted code INSECURE SECURE

slide-15
SLIDE 15

Premise

  • Techniques and ideas from
  • Verification
  • Static Analysis
  • …
  • Can help with this problem

Somesh Jha Retrofitting Legacy Code for Security 15

slide-16
SLIDE 16

Collaborators and Funding

Somesh Jha Retrofitting Legacy Code for Security 16

slide-17
SLIDE 17

The Problem

Somesh Jha Retrofitting Legacy Code for Security 17

slide-18
SLIDE 18

Rewriting Programs for a Capability System

[Harris et. al., Oakland 2013]

  • Basic problem: take an insecure program

and a policy, instrument program to invoke OS primitives to satisfy the policy

  • Key technique: reduce to safety game

between program and instrumentation

Somesh Jha Retrofitting Legacy Code for Security 18

slide-19
SLIDE 19

Capsicum

Somesh Jha Retrofitting Legacy Code for Security 19

slide-20
SLIDE 20

What is Capsicum?

  • Capsicum is a lightweight OS capability

and sandbox framework developed at the University of Cambridge Computer Laboratory

  • supported by grants from Google, the

FreeBSD Foundation, and DARPA.

  • Capsicum extends the POSIX API, providing

several new OS primitives to support object- capability security on UNIX-like operating systems:

Somesh Jha Retrofitting Legacy Code for Security 20

slide-21
SLIDE 21

Capsicum

  • https://www.cl.cam.ac.uk/research/security

/capsicum/

  • The FreeBSD implementation of

Capsicum, developed by Robert Watson and Jonathan Anderson, ships out of the box in FreeBSD 10.0 (and as an optionally compiled feature in FreeBSD 9.0, 9.1, and 9.2)

  • Also available on Linux

Somesh Jha Retrofitting Legacy Code for Security 21

slide-22
SLIDE 22

Running example: gzip

gzip() { files = parse_cl; for (f in files) (in, out) = open; compr(in, out); } compr(in, out) { body; }

22

public_leak.com

slide-23
SLIDE 23

An Informal Policy for gzip

When gzip executes body, it should only be able to read from in and write to out.

23

slide-24
SLIDE 24

Capsicum: An OS with Capabilities

  • Two levels of capability:
  • High Capability (can open files)
  • Low Capability (cannot open files)
  • Rules describing capability:
  • 1. Process initially executes with

capability of its parent

  • 2. Process can invoke the drop system call

to take Low Capability

24

slide-25
SLIDE 25

Securing gzip on Capsicum

gzip() { files = parse_cl; for (f in files) (in, out) = open; compr(in, out); } compr(in, out) { drop(); body; } High Cap. Low Cap.

25

public_leak.com

slide-26
SLIDE 26

compr(in, out) { drop(); body; }

Securing gzip on Capsicum

High Cap. High Cap. High Cap. High Cap. Low Cap.

26

gzip() { files = parse_cl; for (f in files) (in, out) = open; compr(in, out); }

slide-27
SLIDE 27

compr(in, out) { drop(); body; }

Securing gzip on Capsicum

Low Cap. Low Cap.

27

gzip() { files = parse_cl; for (f in files) (in, out) = open; compr(in, out); } ≠ High Cap.

slide-28
SLIDE 28

compr(in, out) { drop(); body; }

Securing gzip on Capsicum

High Cap.

28

gzip() { files = parse_cl; for (f in files) (in, out) = open; compr(in, out); } fork_compr(in, out); Low Cap. High Cap. High Cap.

slide-29
SLIDE 29

compr(in, out) { drop(); body; }

Securing gzip on Capsicum

High Cap. Low Cap.

29

gzip() { files = parse_cl; for (f in files) (in, out) = open; compr(in, out); } fork_compr(in, out);

slide-30
SLIDE 30

State of the Art in Rewriting

Somesh Jha Retrofitting Legacy Code for Security 30

Insecure Program gzip() { … compr(); … } compr(…) { … } Secure Program gzip() { … fork_compr(); … } compr(…) { drop(); … }

gzip should always execute comp() with low cap, but always

  • pen files in main with

high cap

slide-31
SLIDE 31

Insights

Somesh Jha Retrofitting Legacy Code for Security 31

slide-32
SLIDE 32

First Key Insight

Policies are not instrumented programs, and they should be explicit.

Somesh Jha Retrofitting Legacy Code for Security 32

slide-33
SLIDE 33

First Key Insight

Somesh Jha Retrofitting Legacy Code for Security 33

Insecure Program gzip() { … compr(); … } compr(…) { … } Secure Program gzip() { … fork_compr(); … } compr(…) { drop(); … }

gzip should always execute compr() with low cap, but always

  • pen files in main with

high cap Disallowed Executions .* [ compr() with high cap ] | .* [ open() with low cap ]

slide-34
SLIDE 34

Second Key Insight

From an insecure program and policy, we can automatically write a secure program by a solving a two-player safety game. [Harris et. al., CAV 2012]

Somesh Jha Retrofitting Legacy Code for Security 34

slide-35
SLIDE 35

Second Key Insight

Somesh Jha Retrofitting Legacy Code for Security 35

Insecure Program gzip() { … compr(); … } compr(…) { … } Secure Program gzip() { … fork_compr(); … } compr(…) { drop(); … }

Disallowed Executions .* [ compr() with high cap ] | .* [ open() with low cap ]

capweave

slide-36
SLIDE 36

The Technique

Somesh Jha Retrofitting Legacy Code for Security 36

slide-37
SLIDE 37

Weaving as a Game

Two steps:

  • 1. Model uninstrumented program,

policy, and Capsicum as languages/automata

  • 2. From automata, translate weaving

problem to a two-player safety game

Somesh Jha Retrofitting Legacy Code for Security 37

slide-38
SLIDE 38

Step 1: Model

  • Program is a language over

program instructions (Instrs)

  • Policy is a language of instructions paired

with capability (Instrs x Caps)

  • Capsicum is a transducer from

instructions and primitives to capabilities (Instrs U Prims → Caps)

Somesh Jha Retrofitting Legacy Code for Security 38

slide-39
SLIDE 39

Step 2: Construct a Game

  • From models, construct a “game” between

insecure program and instrumentation

  • Program plays instructions (Instrs),

instrumentation plays primitives (Prims)

  • Program wins if it generates

an execution that violates the policy

Somesh Jha Retrofitting Legacy Code for Security 39

slide-40
SLIDE 40

Safety Games: A Primer

Two players: Attacker and Defender Play: Attacker and Defender choose actions in alternation Player goals:

  • Attacker: generate a play accepted by the game
  • Defender: thwart the Attacker

Somesh Jha Retrofitting Legacy Code for Security 40

slide-41
SLIDE 41

fork parse_cl noop drop body body ret compr

  • pen
  • pen

noop drop loop call compr noop join

41

slide-42
SLIDE 42

fork parse_cl noop drop body body ret compr

  • pen
  • pen

noop drop loop call compr noop join

42

slide-43
SLIDE 43

Winning Strategy

Winning strategy: choices that a player can make to always win a game

slide-44
SLIDE 44

fork parse_cl noop drop body body ret compr

  • pen
  • pen

noop drop loop call compr noop join

44

slide-45
SLIDE 45

ret compr / fork parse_cl parse_cl / drop body ret compr

  • pen

noop

loop call compr noop join body / loop / call compr /

  • pen /

noop

45

slide-46
SLIDE 46

Some Details

Somesh Jha Retrofitting Legacy Code for Security 46

slide-47
SLIDE 47

Experimental Highlights

  • capweave policies are small compared to

program size (10’s of lines vs. thousands)

  • capweave instruments most programs fast

enough to be in an edit-compile-run cycle

  • capweave-rewritten programs have

reasonable overhead vs. hand-rewritten

slide-48
SLIDE 48

Name kLoC Pol. Lines Time bzip2 8 70 4m57s gzip 9 68 3m26s php-cgi 852 114 46m36s tar 108 49 0m08s tcpdump 87 52 0m09s wget 64 35 0m10s

capweave Performance

48

slide-49
SLIDE 49

Name Tests Passed Overhead: capweave / hand bzip2 6 6 20.90% gzip 2 2 15.03% php-cgi 11 2 65.64% tar 1 1 64.78% tcpdump 29 27 24.77% wget 4 4 0.91%

Weaved-program Performance

49

slide-50
SLIDE 50

Additional Challenges

  • User Study

– Patterson: “How do you know you are doing better?”

  • Optimizations

– Incorporate quantitative measures into games (e.g., mean-payoff games)

  • User-friendliness

– Better policy language

slide-51
SLIDE 51

The Future

Somesh Jha Retrofitting Legacy Code for Security 51

slide-52
SLIDE 52

OK… but when does it end?

Decentrailized Information Flow

  • Asbestos [SOSP 2005]
  • HiStar [SOSP 2006]
  • Flume [SOSP 2007]*

Analogous problem to capabilities

  • Capabilities ≈ flows
  • drop ≈ labels

* Related work in [Harris et. al., CCS 2010]

slide-53
SLIDE 53

Capsicum

53

Program Policy capweave Capsicum Program Weaver Generator

slide-54
SLIDE 54

HiStar

54

Program Policy hiweave HiStar Program Weaver Generator

slide-55
SLIDE 55

55

Questions

slide-56
SLIDE 56

Summary

Somesh Jha Retrofitting Legacy Code for Security 56

Insecure Program gzip() { … compr(); … } compr(…) { … } Secure Program gzip() { … fork_compr(); … } compr(…) { drop(); … }

Disallowed Executions .* [ compr() with high cap ] | .* [ open() with low cap ]

capweave