Trustworthy Systems from Un-Trusted Components
PRESENTED BY PROF. ABHIK ROYCHOUDHURY NATIONAL UNIVERSITY OF SINGAPORE ABHIK@COMP.NUS.EDU.SG
http://www.comp.nus.edu.sg/~tsunami
Trustworthy Systems from Un-Trusted Components - - PowerPoint PPT Presentation
Trustworthy Systems from Un-Trusted Components http://www.comp.nus.edu.sg/~tsunami PRESENTED BY PROF. ABHIK ROYCHOUDHURY NATIONAL UNIVERSITY OF SINGAPORE ABHIK@COMP.NUS.EDU.SG Enhancing local Ongoing NRF Project Overall capabilities Outlook
PRESENTED BY PROF. ABHIK ROYCHOUDHURY NATIONAL UNIVERSITY OF SINGAPORE ABHIK@COMP.NUS.EDU.SG
http://www.comp.nus.edu.sg/~tsunami
2
Vulnerability Discovery Binary Hardening Verification Data Protection
Agency Collaboration Industry Collaboration Education – NUS (Bachelors in Infosec)
Research Outputs – Publications, Tools, Academic Collaboration, Exchanges, Seminars, Workshops Enhancing local capabilities
Ongoing NRF Project Overall Outlook
Usage and Research impact
Research Visibility
Educational Impact
3
Scholarly Impact
4
AFLFast — 10x faster than AFL
AFLGo — 1st directed greybox fuzzer
5
PRESENTATION TO NRF EXPERT PANEL, FEB 23, 2018
LowFat — Efficient Binary Hardening Detects stack/buffer overflows and type confusion attacks 17% performance overhead (vs. 45% state-of-the-art) 12% memory overhead (vs. 700% state-of-the-art) Integratedwith AFLFast and AFLGo to detect more vulnerabilities more efficiently! 1
6
Certification of software for IoT devices in smart home, smart health, robots/drones Focus on environment aware functionality certification, but also weave in non-functional properties Capabilities for such certification exist in NUS, and some partnerships for translation, but more may be needed.
TSUNAMi Project
to retain efficiency of greybox fuzzing.
[CCS’17]
exploration towards low-frequency paths
Received 2000 USD @Google bug bounty
@DARPA CGC (Team Codejitsu)
[CCS’16, TSE’18]
semantics into account leading to over-condensing, send-bucket and long- tail problems
p1 f1 f2 f3 f4
x x x
b2 b1 b4 b3 b5
Culprit constraint [FASE’17]
12
1 int search(int x, int a[], int length) { 2 int i; 3 for (i=0; i<length; i++) { 4 if (x == a[i]) 5 return i; 6 } 7 return −1; 8 } (a) Correct linear search 1 int search(int x, int a[], int length) { 2 int L = 0; 3 int R = length-1; 4 do { 5 int m = (L+R)/2; 6 if (x == a[m]) { 7 return m; 8 } else if (x < a[m]) { // bug fix: x > a[m] 9 L = m+1; 10 } else { 11 R = m-1; 12 } 13 } while (L <= R); 14 return -1; 15 } (b) Buggy binary search
User-defined condition: length = 3 & a[0] < a[1] < a[2] Verification condition Experiments on embedded Linux Busybox
13
Verification condition Counterexample Is SAT? Negate Patch found Buggy program Is SAT? Angelic forest Is SAT? Component library Candidate patch No Yes Yes Yes Buggy program Reference program Symbolic analysis
[PLDI’18]
[PLDI’18]
server and a website using SSO service
A.com
Username&password User (Client) Identity Provider (IdP) Access token Access token login
formal analysis
Modelling Protocol Extraction Analysis Protocol Modelling Refine Finished? Repeat Refinement Attacker Model Protocol Fuzzing Model Formal Verification Report Report Analysis Confirmed vulnerability Reconstruct Attack Attacker Model SDK Analysis Security Property Network Traces N Y Refined Protocol Verification
cryptographic primitives and reasoning on attacker knowledge bounded sessions
[ICFEM‘17]
and may unboundedly evolving
unbounded evolving of global states
YES NO OR Represent as horn clauses with states Deduction of a targeted rule
Stateful protocol
protocol state change influence
Reasoning
search for the attacker
find a valid evolving trace
Specification Framework Verification Algorithm Result
[ICFEM‘17]
§Leakage via data access patterns is common §Oblivious RAM incurs at best O(log N) overhead for read/write accesses §Key Insight: For read-only data, shuffle & access steps can be parallelized §Our Approach: With √N trusted hardware (SGX) cores on the server
§ Distribute work in each shuffle step to multiple threads § This matches the rate of access and shuffle operations
§Result: Constant latency with sufficient computational cores (80 threads)
§ 0.3 seconds to fetch a block of 256 KB
RQ: Can we achieve “constant latency” for specific case in real applications?
Encrypted RAM Encrypted Cloud Storage Peer-to-peer/ Distributed system Secret keys
User queries Online Behavior
Photos Music PDFs Videos
[NDSS’17]
[NDSS’17]
to prevent Neverbleed
H2O
TOR
FreeTDS
OpenSSL