2012 S&P Paper Reading Session1

S&P 2012 Paper Reading Session 1: System Security

Chong-‐Kuan Chen

Outline

1.  A Framework to Eliminate Backdoors from Response-‐Computable AuthenHcaHon

2.  Safe Loading-‐A FoundaHon for Secure ExecuHon of Untrusted Programs

3.  ReDeBug: Finding Unpatched Code Clones in EnHre OS DistribuHons

A Framework to Eliminate Backdoors from Response-‐Computable Authen<ca<on

Shuaifu Dai, Tao Wei, Chao Zhang, Tielei Wang, Yu Ding, Zhenkai Liang, Wei Zou

Beijing Key Lab of Internet Security Technology University of California, Berkeley

Outline

•  IntroducHon •  Background – AuthenHcaHon Model – Backdoor

•  Proposed Scheme – Explicit response comparison – FuncHon purificaHon – Backdoor usability tesHng

•  EvaluaHon

IntroducHon

•  Formalize authenHcaHon model •  Classify backdoor to response-‐computable authenHcaHon (RCA)

•  Propose new RCA framework to eliminate backdoors

AuthenHcaHon Model

•  The basic authenHcaHon model

•  Two class of authenHcaHon

model –  Direct compare user response and respected response, response-‐computable authenHcaHon (RCA)

–  User response involves in authenHcaHon progress

Response-‐computable AuthenHcaHon

Backdoor A[ack Model

•  The a[acker has chance to modify develop progress but cannot interfere deployment environment

•  A[acker cannot intercept code review and tesHng process. •  OperaHng system is trusted. •  Password database is trusted

•  Examples of backdoor – VSFTPD 2.3.4 Backdoor – Thompson’s compiler backdoor

Type of Backdoor

•  type T1 : bypass response comparison – Depends on user input(U-‐trigger backdoor) – Depends on global states(G-‐trigger backdoor) – Depends on internal states(I-‐trigger backdoor)

•  Type T2 : controlling computaHon of expected response –  Type T2a backdoor's response computaHon depends on informaHon other than challenge and password

–  Type T2b is response computaHon collision-‐based backdoor

Proposed Scheme

•  This RCA framework include –  Explicit response comparison –  FuncHon purificaHon –  Backdoor usability tesHng

Explicit Response Comparison

•  Decouple verificaHon process – Response computaHon – Response comparison

•  Explicit Response Comparison – Response comparison compare user response and respect response only

•  This step can eliminate T1 backdoor

FuncHon purificaHon

•  Pure funcHon’s characters – Without side effects –  DeterminisHc

•  This step ensure response computaHon is a pure funcHon –  Only challenge and password involve in response computaHon

•  NaPu components employ a funcHon level sandbox –  Global state isolaHon –  Internal state reset.

•  Acer this step T2a backdoors are eliminated.

Backdoor usability tesHng

•  This step use collision tesHng – Use sampling to check collision probability – find out high collision algorithms

•  Eliminated T2b backdoors.

Overview of Scheme

EvaluaHon

•  Performance overhead •  Backdoor usability tesHng •  Volunteer-‐created backdoor

Safe Loading-‐AFounda<on for Secure Execu<on of Untrusted Programs

Mathias Payer, Tobias Hartmann and Thomas R. Gross ETH Zurich, Switzerland

Outline

•  IntroducHon •  Background –  Socware-‐based fault isolaHon –  Binary TranslaHon –  Policy-‐based system call authorizaHon

•  A[ack Vector To Loader –  ExploiHng the standard loader –  The late intercepHon problem –  The loader black box

•  Proposed Scheme •  EvaluaHon

IntroducHon

•  SFI was deployed widely to secure program execuHon

•  Standard loader exposes secure risk to escape SFI

•  This paper replaces standard loader by secure loader out of sandbox to eliminate a[ack to loader

Socware-‐based Fault IsolaHon

•  Socware-‐based fault isolaHon(SFI) has been proposed to secure program execuHon

•  With FFI framework, many security features can be implement –  ASLR, DEP, stack canaries

•  Most of SFI frameworks employ following technique –  Binary TranslaHon –  Policy-‐based system call authorizaHon

Binary TranslaHon

•  Binary TranslaHon (BT) – Libdetox, Vx32, Strata sanbox system –  Instrument applicaHon behavior

Policy-‐based System Call AuthorizaHon

•  Policy-‐based system call authorizaHon – System call trace from sandbox – Pre-‐defined policy – To make decision if the system call can be executed

A[ack Vector to Loader

•  ExploiHng the standard loader •  The late intercepHon problem •  The loader black box

ExploiHng the standard loader

•  Increasing complexity of standard loader bring in security risk – Preload alternate libraries – Replace the standard search path – Escalate privileges

The Late IntercepHon Problem

•  ApplicaHon, BT and loader share the same memory space – Loader may leak memory layout informaHon – Break integrity of the BT

The Loader Black Box

•  In previous work, loader is the black box and translated as applicaHon – ApplicaHon must has privileges to load code – Sandbox has no informaHon about memory layout

Safe Loading

•  A lightweight secure loader and move secure loader into sandbox

Privilege Separate

•  Divide applicaHon into two domain – Sandbox domain and applicaHon domain

•  Sandbox domain (secure loader and sandbox) – Ensure only checked code loaded

•  ApplicaHon domain –  Indirect control flow transfer will be checked by sandbox domain

SoluHon to Standard Sandbox

•  RestricHng Privilege EscalaHon A[ack – Secure loader only need to relocate code and thus reduce a[ack vector

•  ProtecHng All Executed ApplicaHon Code •  Opening the Loader Black Box

Performance EvaluaHon

Security Feature

ReDeBug: Finding Unpatched Code Clones in EnHre OS DistribuHons

Jiyong Jang, Abeer Agrawal, and David Brumley Carnegie Mellon University

IntroducHon

•  Patch is the standard process to fix and update buggy code

•  Code clone is ocen appear in OS distribuHon – Bad programming style –  Independent of sub-‐component –  It is hard to discover code clones in OS

•  This paper propose system finding unpatched code clones in OS-‐distribuHon

Example of Code Clone

•  CVE-‐2009-‐3720 is exploit discovered and fixed in 2009

•  But the same code clone appear 386 Hmes across Debian, Ubuntu package

Related Work

•  Most previous work like MOSS, CCFinde – DetecHon all code clone in system – Not scale enough to OS level – Language-‐dependent

ReDeBug

•  This paper propose ReDeBug system to find code clone –  Flexible scalability –  Language agnosHc –  Lower false detecHon rate

•  ReDeBug find code clone by folowing steps –  Pre-‐process the source to construct source database –  Check for unpatched code copies –  Post-‐process to find exactly matching code

ReDeBug Workflow

Pre-‐process

1.  Performs normalizaHon and tokenizaHon 2.  Moves an n-‐length window over the token

stream. For each window, the resulHng n-‐tokens are hashed into a Bloom filter

3.  Stores the Bloom filter for each source file in a raw data format

NormalizaHon

•  Each line as a basic unit – Remove comments – Non-‐ASCII characters – Redundant whitespace and newline – Convert to lower case

TokenizaHon

•  Slides a window of length n – Every n consecuHve unit will use to compare – Following are sample where n=2

1 2 3 4 5

1 2 2 3 3 4 4 5

Bloom Filter

Add element

Check element

Check for Unpatched Code Copies

1.  Extracts the original code snippet and the c tokens of context informaHon from the pre-‐patch source

2.  Normalizes and tokenizes the extracted original buggy code snippets

3.  Hashes the n-‐token window into a set of hashes

4.  Bloom filter set membership test

Post-‐process

1.  Performs an exact-‐matching test 2.  Excludes dead code 3.  reports only non-‐dead code to the user

Database Build Time

Query Time

Q&A

Login Request

Challenge

Response

server client

Compute response

Compute response

’

AuthenHcaHon Check

Engineering

2012 S&P Paper Reading Session1