2012 S&P Paper Reading Session1
-
Upload
- -
Category
Engineering
-
view
105 -
download
1
description
Transcript of 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