SECOMP Efficient Formally Secure Compilers to a Tagged Architecture. Cătălin Hrițcu INRIA Paris
|
|
|
- Jesse Thompson
- 5 years ago
- Views:
Transcription
1 SECOMP Efficient Formally Secure Compilers to a Tagged Architecture Cătălin Hrițcu INRIA Paris 1
2 SECOMP Efficient Formally Secure Compilers to a Tagged Architecture Cătălin Hrițcu INRIA Paris 5 year vision 1
3 SECOMP Efficient Formally Secure Compilers to a Tagged Architecture Cătălin Hrițcu INRIA Paris 5 year vision fresh grant 1
4 The problem: devastating low-level attacks 1. inherently insecure low-level languages (C, C++) memory unsafe: any buffer overflow can be catastrophic allowing remote attackers to gain complete control 2
5 The problem: devastating low-level attacks 1. inherently insecure low-level languages (C, C++) memory unsafe: any buffer overflow can be catastrophic allowing remote attackers to gain complete control 2. unsafe interoperability with lower-level code even code written in safer high-level languages (Java, C#, OCaml) has to interoperate with insecure low-level libraries (C, C++, ASM) unsafe interoperability: all high-level safety guarantees lost 2
6 The problem: devastating low-level attacks 1. inherently insecure low-level languages (C, C++) memory unsafe: any buffer overflow can be catastrophic allowing remote attackers to gain complete control 2. unsafe interoperability with lower-level code even code written in safer high-level languages (Java, C#, OCaml) has to interoperate with insecure low-level libraries (C, C++, ASM) unsafe interoperability: all high-level safety guarantees lost Today s languages & compilers plagued by low-level attacks main culprit: hardware provides no appropriate security mechanisms fixing this purely in software would be way too inefficient 2
7 Key enabler: Micro-Policies software-defined, hardware-accelerated, tag-based monitoring 3
8 Key enabler: Micro-Policies software-defined, hardware-accelerated, tag-based monitoring pc r0 r1 mem[0] store r0 r1 mem[2] mem[3] 3
9 Key enabler: Micro-Policies software-defined, hardware-accelerated, tag-based monitoring pc tpc mem[0] tm0 r0 tr0 store r0 r1 tm1 r1 tr1 mem[2] tm2 mem[3] tm3 3
10 Key enabler: Micro-Policies software-defined, hardware-accelerated, tag-based monitoring pc tpc mem[0] tm0 r0 tr0 store r0 r1 tm1 r1 tr1 mem[2] tm2 mem[3] tm3 tpc tr0 tr1 tm3 tm1 store monitor 3
11 Key enabler: Micro-Policies software-defined, hardware-accelerated, tag-based monitoring pc tpc mem[0] tm0 r0 tr0 store r0 r1 tm1 r1 tr1 mem[2] tm2 mem[3] tm3 tpc tr0 tr1 tm3 tm1 = store monitor allow tpc tm3 3
12 Key enabler: Micro-Policies software-defined, hardware-accelerated, tag-based monitoring pc tpc mem[0] tm0 r0 tr0 store r0 r1 tm1 r1 tr1 mem[2] tm2 mem[3] tm3 tpc tr0 tr1 tm3 tm1 = store monitor allow tpc tm3 3
13 Key enabler: Micro-Policies software-defined, hardware-accelerated, tag-based monitoring pc tpc mem[0] tm0 r0 tr0 store r0 r1 tm1 r1 tr1 mem[2] tm2 mem[3] tm3 store tpc tr0 tr1 tm3 tm1 monitor allow = tpc tm3 software monitor s decision is hardware cached 3
14 Key enabler: Micro-Policies software-defined, hardware-accelerated, tag-based monitoring pc tpc mem[0] tm0 r0 tr0 store r0 r1 tm1 r1 tr1 mem[2] tm2 mem[3] tm3 tpc tr0 tr1 tm3 tm1 = store monitor disallow policy violation stopped! (e.g. out of bounds write) 3
15 Micro-policies are cool! low level + fine grained: unbounded per-word metadata, checked & propagated on each instruction 4
16 Micro-policies are cool! low level + fine grained: unbounded per-word metadata, checked & propagated on each instruction flexible: tags and monitor defined by software efficient: hardware caching, <10% overhead heap safety, control-flow integrity, taint tracking expressive: complex policies for secure compilation secure and simple enough to verify security in Coq real: FPGA implementation on top of RISC-V [Oakland 13 & 15, POPL 14, ASPLOS 15] 4
17 SECOMP grand challenge Use micro-policies to build the first efficient formally secure compilers for realistic programming languages 5
18 SECOMP grand challenge Use micro-policies to build the first efficient formally secure compilers for realistic programming languages 1. Provide secure semantics for low-level languages C with protected components and memory safety 5
19 SECOMP grand challenge Use micro-policies to build the first efficient formally secure compilers for realistic programming languages 1. Provide secure semantics for low-level languages C with protected components and memory safety 2. Enforce secure interoperability with lower-level code ASM, C, and F* [F* = ML + verification] 5
20 Formally verify: full abstraction holy grail of secure compilation, enforcing abstractions all the way down 6
21 Formally verify: full abstraction holy grail of secure compilation, enforcing abstractions all the way down whole program behavior source compiler correctness (e.g. CompCert) compiler whole program behavior target 6
22 Formally verify: full abstraction holy grail of secure compilation, enforcing abstractions all the way down whole program behavior source component compiler correctness (e.g. CompCert) not enough compiler full abstraction whole program behavior target component low-level attacker 6
23 Formally verify: full abstraction holy grail of secure compilation, enforcing abstractions all the way down whole program behavior source component high-level attacker compiler correctness (e.g. CompCert) not enough compiler full abstraction whole program behavior target component low-level attacker 6
24 Formally verify: full abstraction holy grail of secure compilation, enforcing abstractions all the way down whole program behavior source component high-level attacker compiler correctness (e.g. CompCert) not enough compiler full abstraction whole program behavior target component protected low-level attacker no extra power 6
25 Formally verify: full abstraction holy grail of secure compilation, enforcing abstractions all the way down whole program behavior source component high-level attacker secure compiler correctness (e.g. CompCert) not enough full abstraction whole program behavior secure Benefit: sound security reasoning in the source language forget about compiler chain (linker, loader, runtime system) forget that libraries are written in a lower-level language 6
26 SECOMP: achieving full abstraction at scale F* language (ML + verification) mitls* C language + memory safety + components 7
27 SECOMP: achieving full abstraction at scale F* language (ML + verification) C language + memory safety + components SecF* + SecML mitls* 7
28 SECOMP: achieving full abstraction at scale F* language (ML + verification) C language + memory safety + components SecF* + SecML mitls* memory safe C component 7
29 SECOMP: achieving full abstraction at scale F* language (ML + verification) C language + memory safety + components SecF* + SecML mitls* memory safe C component 7
30 SECOMP: achieving full abstraction at scale F* language (ML + verification) C language + memory safety + components SecF* + SecML CompSec + mitls* memory safe C component ASM language (RISC-V + micro-policies) 7
31 SECOMP: achieving full abstraction at scale F* language (ML + verification) mitls* SecF* + SecML C language + memory safety + components CompSec + memory safe C component legacy C component CompSec ASM language (RISC-V + micro-policies) ASM component 7
32 SECOMP: achieving full abstraction at scale F* language (ML + verification) mitls* SecF* + SecML C language + memory safety + components CompSec + memory safe C component legacy C component CompSec ASM language (RISC-V + micro-policies) ASM component protecting component boundaries 7
33 SECOMP: achieving full abstraction at scale F* language (ML + verification) mitls* SecF* + SecML C language + memory safety + components CompSec + memory safe C component legacy C component CompSec ASM language (RISC-V + micro-policies) ASM component protecting component boundaries 7
34 SECOMP: achieving full abstraction at scale F* language (ML + verification) protecting higher-level abstractions mitls* SecF* + SecML C language + memory safety + components CompSec + memory safe C component legacy C component CompSec ASM language (RISC-V + micro-policies) ASM component protecting component boundaries 7
35 Protecting component boundaries Add mutually distrustful components to C interacting only via strictly enforced interfaces 8
36 Protecting component boundaries Add mutually distrustful components to C interacting only via strictly enforced interfaces CompSec compiler chain (based on CompCert) propagate interface information to produced binary 8
37 Protecting component boundaries Add mutually distrustful components to C interacting only via strictly enforced interfaces CompSec compiler chain (based on CompCert) propagate interface information to produced binary Micro-policy simultaneously enforcing component separation type-safe procedure call and return discipline 8
38 Protecting component boundaries Add mutually distrustful components to C interacting only via strictly enforced interfaces CompSec compiler chain (based on CompCert) propagate interface information to produced binary Micro-policy simultaneously enforcing component separation type-safe procedure call and return discipline Interesting attacker model extending full abs. to mutual distrust + unsafe source 8
39 Protecting component boundaries Add mutually distrustful components to C interacting only via strictly enforced interfaces CompSec compiler chain (based on CompCert) propagate interface information to produced binary Micro-policy simultaneously enforcing component separation type-safe procedure call and return discipline Interesting attacker model extending full abs. to mutual distrust + unsafe source Recent preliminary work, joint with Yannis Juglaret et al 8
40 Compartmentalization micro-policy memory registers Jal pc... r C @EntryPoint Store r a r m... C 2 Load r m r a Jump r a [Towards a Fully Abstract Compiler Using Micro-Policies, Juglaret, Hritcu, et al, TR 2015] 9
41 Compartmentalization micro-policy C 1 C 2 memory Jal r @entrypoint Store r a r m... Load r m r a Jump r pc stack level current color registers... r [Towards a Fully Abstract Compiler Using Micro-Policies, Juglaret, Hritcu, et al, TR 2015] 9
42 Compartmentalization micro-policy memory registers Jal pc... r C stack level current color cross-component call only allowed at EntryPoint...@EntryPoint Store r a r m... C 2 Load r m r a Jump r a [Towards a Fully Abstract Compiler Using Micro-Policies, Juglaret, Hritcu, et al, TR 2015] 9
43 Compartmentalization micro-policy memory registers C 1 C 2 Jal r @entrypoint pc r a... Store r a r m... Load r m n Jump r a [Towards a Fully Abstract Compiler Using Micro-Policies, Juglaret, Hritcu, et al, TR 2015] 9
44 Compartmentalization micro-policy memory registers C 1 C 2 Jal r @entrypoint pc r a... increment Store r a r m... Load r m r a linear return n changed Jump r a [Towards a Fully Abstract Compiler Using Micro-Policies, Juglaret, Hritcu, et al, TR 2015] 9
45 Compartmentalization micro-policy C 1 C 2 memory Jal r @entrypoint Store r a r m... Load r m r a Jump r a registers linear return pc r a r m [Towards a Fully Abstract Compiler Using Micro-Policies, Juglaret, Hritcu, et al, TR 2015] 9
46 Compartmentalization micro-policy C 1 C 2 memory Jal r @entrypoint Store r a r m... Load r m r a Jump r a registers linear return pc r a r m loads and stores to the same component always allowed 9
47 Compartmentalization micro-policy memory registers Jal r C linear return n...@entrypoint Store r a r pc r a r m C 2 Load r m r a Jump r a 9
48 Compartmentalization micro-policy C 1 memory Jal r linear return n n invariant: at most one return capability per call stack level...@entrypoint Store r a r pc r a r m C 2 Load r m r a Jump r a 9
49 Compartmentalization micro-policy C 1 memory Jal r linear return n n invariant: at most one return capability per call stack level...@entrypoint Store r a r m... C 2 Load r m r a Jump r pc r a r m 9
50 Compartmentalization micro-policy C 1 memory Jal r linear return n n invariant: at most one return capability per call stack level...@entrypoint Store r a r m... cross-component return only allowed via return capability C 2 Load r m r a Jump r pc r a r m 9
51 Secure compartmentalizing compilation compromise scenarios. i 1 i 2 i 3 i 4 i 5 C 1 C 2 C 3 C 4 C 5 10
52 Secure compartmentalizing compilation compromise scenarios. i 1 i 2 i 3 i 4 i 5 i 1 i 2 i 3 i 4 i 5 C 1 C 2 C 3 C 4 C 5 L D 1 C 2 D 3 C 4 C 5 10
53 Secure compartmentalizing compilation compromise scenarios. i 1 i 2 i 3 i 4 i 5 C 1 A 2 C 3 A 4 A 5 H i 1 i 2 i 3 i 4 i 5 D 1 A 2 D 3 A 4 A 5 low-level attack from compromised C 2, C 4, C 5 high-level attack from some fully defined A 2, A 4, A 5 i 1 i 2 i 3 i 4 i 5 i 1 i 2 i 3 i 4 i 5 C 1 C 2 C 3 C 4 C 5 L D 1 C 2 D 3 C 4 C 5 10
54 Secure compartmentalizing compilation compromise scenarios. i 1 i 2 i 3 i 4 i 5 C 1 A 2 C 3 A 4 A 5 H i 1 i 2 i 3 i 4 i 5 D 1 A 2 D 3 A 4 A 5 low-level attack from compromised C 2, C 4, C 5 high-level attack from some fully defined A 2, A 4, A 5 i 1 i 2 i 3 i 4 i 5 i 1 i 2 i 3 i 4 i 5 C 1 C 2 C 3 C 4 C 5 L D 1 C 2 D 3 C 4 C 5 follows from structured full abstraction for unsafe languages + separate compilation [Beyond Good and Evil, Juglaret, Hritcu, et al, CSF 16] 10
55 Protecting higher-level abstractions ML abstractions we want to enforce with micro-policies types, value immutability, opaqueness of closures, parametricity (dynamic sealing), GC vs malloc/free,... 11
56 Protecting higher-level abstractions ML abstractions we want to enforce with micro-policies types, value immutability, opaqueness of closures, parametricity (dynamic sealing), GC vs malloc/free,... F*: enforcing full specifications using micro-policies some can be turned into contracts, checked dynamically fully abstract compilation of F* to ML trivial for ML interfaces (because F* allows and tracks effects, as opposed to Coq) 11
57 Protecting higher-level abstractions ML abstractions we want to enforce with micro-policies types, value immutability, opaqueness of closures, parametricity (dynamic sealing), GC vs malloc/free,... F*: enforcing full specifications using micro-policies some can be turned into contracts, checked dynamically fully abstract compilation of F* to ML trivial for ML interfaces (because F* allows and tracks effects, as opposed to Coq) Limits of purely-dynamic enforcement functional purity, termination, relational reasoning 11
58 Protecting higher-level abstractions ML abstractions we want to enforce with micro-policies types, value immutability, opaqueness of closures, parametricity (dynamic sealing), GC vs malloc/free,... F*: enforcing full specifications using micro-policies some can be turned into contracts, checked dynamically fully abstract compilation of F* to ML trivial for ML interfaces (because F* allows and tracks effects, as opposed to Coq) Limits of purely-dynamic enforcement functional purity, termination, relational reasoning push these limits further and combine with static analysis 11
59 Micro-policies: remaining fundamental challenges 12
60 Micro-policies: remaining fundamental challenges Micro-policies for C and ML needed for vertical compiler composition will put micro-policies in the hands of programmers 12
61 Micro-policies: remaining fundamental challenges Micro-policies for C and ML needed for vertical compiler composition will put micro-policies in the hands of programmers Secure micro-policy composition micro-policies are interferent reference monitors one micro-policy s behavior can break another s guarantees e.g. composing anything with IFC can leak 12
62 SECOMP in a nutshell We need more secure languages, compilers, hardware 13
63 SECOMP in a nutshell We need more secure languages, compilers, hardware Key enabler: micro-policies (software-hardware protection) Grand challenge: the first efficient formally secure compilers for realistic programming languages (C, ML, F*) 13
64 SECOMP in a nutshell We need more secure languages, compilers, hardware Key enabler: micro-policies (software-hardware protection) Grand challenge: the first efficient formally secure compilers for realistic programming languages (C, ML, F*) Answering challenging fundamental questions attacker models, composition, micro-policies for C and ML 13
65 SECOMP in a nutshell We need more secure languages, compilers, hardware Key enabler: micro-policies (software-hardware protection) Grand challenge: the first efficient formally secure compilers for realistic programming languages (C, ML, F*) Answering challenging fundamental questions attacker models, composition, micro-policies for C and ML Achieving strong security properties like full abstraction + testing and proving formally that this is the case 13
66 SECOMP in a nutshell We need more secure languages, compilers, hardware Key enabler: micro-policies (software-hardware protection) Grand challenge: the first efficient formally secure compilers for realistic programming languages (C, ML, F*) Answering challenging fundamental questions attacker models, composition, micro-policies for C and ML Achieving strong security properties like full abstraction + testing and proving formally that this is the case Measuring & lowering the cost of secure compilation 13
67 SECOMP in a nutshell We need more secure languages, compilers, hardware Key enabler: micro-policies (software-hardware protection) Grand challenge: the first efficient formally secure compilers for realistic programming languages (C, ML, F*) Answering challenging fundamental questions attacker models, composition, micro-policies for C and ML Achieving strong security properties like full abstraction + testing and proving formally that this is the case Measuring & lowering the cost of secure compilation Most of this is vaporware at this point but... trying to build a community and looking for collaborators & students & PostDocs to try to make some of this real 13
Compartmentalizing Formally Secure Compilation
Compartmentalizing Formally Secure Compilation Cătălin Hrițcu Inria Paris https://secure-compilation.github.io 1 0. Compiler correctness Course outline as Trace Property Preservation 1. Secure interoperability
Manifest Safety and Security. Robert Harper Carnegie Mellon University
Manifest Safety and Security Robert Harper Carnegie Mellon University Collaborators This work is, in part, joint with Lujo Bauer, Karl Crary, Peter Lee, Mike Reiter, and Frank Pfenning at Carnegie Mellon.
CSE Computer Security
CSE 543 - Computer Security Lecture 17 - Language-based security October 25, 2007 URL: http://www.cse.psu.edu/~tjaeger/cse543-f07/ 1 Engineering Disaster? Millions of Bots Compromised applications Programming
CSE Computer Security (Fall 2006)
CSE 543 - Computer Security (Fall 2006) Lecture 22 - Language-based security November 16, 2006 URL: http://www.cse.psu.edu/~tjaeger/cse543-f06/ 1 The Morris Worm Robert Morris, a 23 doctoral student from
CHERI A Hybrid Capability-System Architecture for Scalable Software Compartmentalization
CHERI A Hybrid Capability-System Architecture for Scalable Software Compartmentalization Robert N.M. Watson *, Jonathan Woodruff *, Peter G. Neumann, Simon W. Moore *, Jonathan Anderson, David Chisnall
Micro-Policies: Formally Verified, Tag-Based Security Monitors
Portland State University PDXScholar Computer Science Faculty Publications and Presentations Computer Science 5-2015 Micro-Policies: Formally Verified, Tag-Based Security Monitors Arthur Azevedo de Amorim
HDFI: Hardware-Assisted Data-flow Isolation
HDFI: Hardware-Assisted Data-flow Isolation Presented by Ben Schreiber Chengyu Song 1, Hyungon Moon 2, Monjur Alam 1, Insu Yun 1, Byoungyoung Lee 1, Taesoo Kim 1, Wenke Lee 1, Yunheung Paek 2 1 Georgia
INFLUENTIAL OPERATING SYSTEM RESEARCH: SECURITY MECHANISMS AND HOW TO USE THEM CARSTEN WEINHOLD
Faculty of Computer Science Institute of Systems Architecture, Operating Systems Group INFLUENTIAL OPERATING SYSTEM RESEARCH: SECURITY MECHANISMS AND HOW TO USE THEM CARSTEN WEINHOLD OVERVIEW Fundamental
Labels and Information Flow
Labels and Information Flow Robert Soulé March 21, 2007 Problem Motivation and History The military cares about information flow Everyone can read Unclassified Few can read Top Secret Problem Motivation
Using the Singularity Research Development Kit
Using the Research Development Kit James Larus & Galen Hunt Microsoft Research ASPLOS 08 Tutorial March 1, 2008 Outline Overview (Jim) Rationale & key decisions architecture Details (Galen) Safe Languages
COS 320. Compiling Techniques
Topic 5: Types COS 320 Compiling Techniques Princeton University Spring 2016 Lennart Beringer 1 Types: potential benefits (I) 2 For programmers: help to eliminate common programming mistakes, particularly
Inject malicious code Call any library functions Modify the original code
Inject malicious code Call any library functions Modify the original code 2 Sadeghi, Davi TU Darmstadt 2012 Secure, Trusted, and Trustworthy Computing Chapter 6: Runtime Attacks 2 3 Sadeghi, Davi TU Darmstadt
SoK: Eternal War in Memory
SoK: Eternal War in Memory László Szekeres, Mathias Payer, Tao Wei, Dawn Song Presenter: Wajih 11/7/2017 Some slides are taken from original S&P presentation 1 What is SoK paper? Systematization of Knowledge
CS558 Programming Languages
CS558 Programming Languages Fall 2016 Lecture 3a Andrew Tolmach Portland State University 1994-2016 Formal Semantics Goal: rigorous and unambiguous definition in terms of a wellunderstood formalism (e.g.
Language Techniques for Provably Safe Mobile Code
Language Techniques for Provably Safe Mobile Code Frank Pfenning Carnegie Mellon University Distinguished Lecture Series Computing and Information Sciences Kansas State University October 27, 2000 Acknowledgments:
CS 161 Computer Security
Paxson Spring 2011 CS 161 Computer Security Discussion 1 January 26, 2011 Question 1 Buffer Overflow Mitigations Buffer overflow mitigations generally fall into two categories: (i) eliminating the cause
Adam Chlipala University of California, Berkeley ICFP 2006
Modular Development of Certified Program Verifiers with a Proof Assistant Adam Chlipala University of California, Berkeley ICFP 2006 1 Who Watches the Watcher? Program Verifier Might want to ensure: Memory
DOVER A Metadata- Extended RISC- V
DOVER A Metadata- Extended RISC- V André DeHon andre@acm.org Eli Boling, Rishiyur Nikhil, Darius Rad, Julie Schwarz Niraj Sharma, Joseph Stoy, Greg Sullivan, Andrew Sutherland Draper 1/6/2016 1 Story Non-
0x1A Great Papers in Computer Security
CS 380S 0x1A Great Papers in Computer Security Vitaly Shmatikov http://www.cs.utexas.edu/~shmat/courses/cs380s/ slide 1 Reference Monitor Observes execution of the program/process At what level? Possibilities:
Pierce Ch. 3, 8, 11, 15. Type Systems
Pierce Ch. 3, 8, 11, 15 Type Systems Goals Define the simple language of expressions A small subset of Lisp, with minor modifications Define the type system of this language Mathematical definition using
Ironclad C++ A Library-Augmented Type-Safe Subset of C++
Ironclad C++ A Library-Augmented Type-Safe Subset of C++ Christian DeLozier, Richard Eisenberg, Peter-Michael Osera, Santosh Nagarakatte*, Milo M. K. Martin, and Steve Zdancewic October 30, 2013 University
'Safe' programming languages
Software Security Language-based Security: 'Safe' programming languages Erik Poll 1 Language-based security Security features & guarantees provided by programming language safety guarantees, incl. memory-safety,
CS527 Software Security
Security Policies Purdue University, Spring 2018 Security Policies A policy is a deliberate system of principles to guide decisions and achieve rational outcomes. A policy is a statement of intent, and
PRESENTED BY: SANTOSH SANGUMANI & SHARAN NARANG
PRESENTED BY: SANTOSH SANGUMANI & SHARAN NARANG Table of contents Introduction Binary Disassembly Return Address Defense Prototype Implementation Experimental Results Conclusion Buffer Over2low Attacks
CS 6V Control-Flow Integrity Principles, Implementations, and Applications. Sureshbabu Murugesan
CS 6V81-05 Control-Flow Integrity Principles, Implementations, and Applications Sureshbabu Murugesan Department of Computer Science University of Texas at Dallas February 29 th, 2012 Outline 1 Overview
Honours/Master/PhD Thesis Projects Supervised by Dr. Yulei Sui
Honours/Master/PhD Thesis Projects Supervised by Dr. Yulei Sui Projects 1 Information flow analysis for mobile applications 2 2 Machine-learning-guide typestate analysis for UAF vulnerabilities 3 3 Preventing
CSE 565 Computer Security Fall 2018
CSE 565 Computer Security Fall 2018 Lecture 14: Software Security Department of Computer Science and Engineering University at Buffalo 1 Software Security Exploiting software vulnerabilities is paramount
CS558 Programming Languages
CS558 Programming Languages Winter 2017 Lecture 4a Andrew Tolmach Portland State University 1994-2017 Semantics and Erroneous Programs Important part of language specification is distinguishing valid from
Region-Based Memory Management in Cyclone
Region-Based Memory Management in Cyclone Dan Grossman Cornell University June 2002 Joint work with: Greg Morrisett, Trevor Jim (AT&T), Michael Hicks, James Cheney, Yanling Wang Cyclone A safe C-level
Hybrid Verification in SPARK 2014: Combining Formal Methods with Testing
IEEE Software Technology Conference 2015 Hybrid Verification in SPARK 2014: Combining Formal Methods with Testing Steve Baird Senior Software Engineer Copyright 2014 AdaCore Slide: 1 procedure Array_Indexing_Bug
A program execution is memory safe so long as memory access errors never occur:
A program execution is memory safe so long as memory access errors never occur: Buffer overflows, null pointer dereference, use after free, use of uninitialized memory, illegal free Memory safety categories
Simply-Typed Lambda Calculus
#1 Simply-Typed Lambda Calculus #2 Back to School What is operational semantics? When would you use contextual (small-step) semantics? What is denotational semantics? What is axiomatic semantics? What
Cryptographically Sound Implementations for Typed Information-Flow Security
FormaCrypt, Nov 30. 2007 Cryptographically Sound Implementations for Typed Information-Flow Security Cédric Fournet Tamara Rezk Microsoft Research INRIA Joint Centre http://msr-inria.inria.fr/projects/sec/cflow
Towards information-flow aware automatic memory management
Towards information-flow aware automatic memory management Aslan Askarov Aarhus University joint work w/ Mathias Pedersen INRIA Rennes 2017-01-27 2 2 I want to compute my taxes! I want to compute my taxes!
Micro- Policies A Framework for Tag- Based Security Monitors
Micro- Policies A Framework for Tag- Based Security Monitors Benjamin C. Pierce University of Pennsylvania and Chalmers University with Arthur Azevedo de Amorim, Silviu Chiarescu, Andre Dehon, Maxime Dénès,
Inline Reference Monitoring Techniques
Inline Reference Monitoring Techniques In the last lecture, we started talking about Inline Reference Monitors. The idea is that the policy enforcement code runs with the same address space as the code
C and C++ Secure Coding 4-day course. Syllabus
C and C++ Secure Coding 4-day course Syllabus C and C++ Secure Coding 4-Day Course Course description Secure Programming is the last line of defense against attacks targeted toward our systems. This course
Software Security II: Memory Errors - Attacks & Defenses
1 Software Security II: Memory Errors - Attacks & Defenses Chengyu Song Slides modified from Dawn Song 2 Administrivia Lab1 Writeup 3 Buffer overflow Out-of-bound memory writes (mostly sequential) Allow
Separate compilation. Topic 6: Runtime Environments p.1/21. CS 526 Topic 6: Runtime Environments The linkage convention
Runtime Environment The Procedure Abstraction and Separate Compilation Topics we will cover The procedure abstraction and linkage conventions Runtime storage convention Non-local data access (brief) These
Control Flow Integrity & Software Fault Isolation. David Brumley Carnegie Mellon University
Control Flow Integrity & Software Fault Isolation David Brumley Carnegie Mellon University Our story so far Unauthorized Control Information Tampering http://propercourse.blogspot.com/2010/05/i-believe-in-duct-tape.html
Buffer overflow background
and heap buffer background Comp Sci 3600 Security Heap Outline and heap buffer Heap 1 and heap 2 3 buffer 4 5 Heap Outline and heap buffer Heap 1 and heap 2 3 buffer 4 5 Heap Address Space and heap buffer
Identity-based Access Control
Identity-based Access Control The kind of access control familiar from operating systems like Unix or Windows based on user identities This model originated in closed organisations ( enterprises ) like
Module: Programming Language Security. Professor Patrick McDaniel Spring CMPSC443 - Introduction to Computer and Network Security
CMPSC443 - Introduction to Computer and Network Security Module: Programming Language Security Professor Patrick McDaniel Spring 2009 1 Engineering Disaster? Millions of Bots Compromised applications Programming
Advanced Topics: Reasoning About Code Pointers & Self- Modifying Code
Advanced Topics: Reasoning About Code Pointers & Self- Modifying Code Zhong Shao Yale University July 25, 2012 Building fully certified systems One logic for all code Consider all possible interactions.
Software Speculative Multithreading for Java
Software Speculative Multithreading for Java Christopher J.F. Pickett and Clark Verbrugge School of Computer Science, McGill University {cpicke,clump}@sable.mcgill.ca Allan Kielstra IBM Toronto Lab kielstra@ca.ibm.com
Buffer Overflow Attacks
Buffer Overflow Attacks 1. Smashing the Stack 2. Other Buffer Overflow Attacks 3. Work on Preventing Buffer Overflow Attacks Smashing the Stack An Evil Function void func(char* inp){ } char buffer[16];
Beyond the PDP-11: Architectural support for a memory-safe C abstract machine
Trustworthy Systems Research and CTSRDCRASH-worthy Development Beyond the PDP-11: Architectural support for a memory-safe C abstract machine David Chisnall, Colin Rothwell, Brooks Davis, Robert N.M. Watson,
Confinement (Running Untrusted Programs)
Confinement (Running Untrusted Programs) Chester Rebeiro Indian Institute of Technology Madras Untrusted Programs Untrusted Application Entire Application untrusted Part of application untrusted Modules
Practical Affine Types and Typestate-Oriented Programming
Practical Affine Types and Typestate-Oriented Programming Philipp Haller KTH Royal Institute of Technology Stockholm, Sweden Dagstuhl Seminar 17051 Theory and Applications of Behavioural Types Schloss
Lecture 4 September Required reading materials for this class
EECS 261: Computer Security Fall 2007 Lecture 4 September 6 Lecturer: David Wagner Scribe: DK Moon 4.1 Required reading materials for this class Beyond Stack Smashing: Recent Advances in Exploiting Buffer
Secure Software Development: Theory and Practice
Secure Software Development: Theory and Practice Suman Jana MW 2:40-3:55pm 415 Schapiro [SCEP] *Some slides are borrowed from Dan Boneh and John Mitchell Software Security is a major problem! Why writing
Secure Systems 2.0: Revisiting and Rethinking the Challenges of Secure System Design. Todd Austin University of Michigan
Secure Systems 2.0: Revisiting and Rethinking the Challenges of Secure System Design Todd Austin University of Michigan The Security Arms Race Question: Why are systems never safe? We deploy our designs
Module: Future of Secure Programming
Module: Future of Secure Programming Professor Trent Jaeger Penn State University Systems and Internet Infrastructure Security Laboratory (SIIS) 1 Programmer s Little Survey Problem What does program for
Language-Based Information- Flow Security
Language-Based Information- Flow Security Andrei Sabelfeld Andrew C. Myers Presented by Shiyi Wei About the paper Literature review Information flow security Static program analysis to enforce information-flow
High-Level Language VMs
High-Level Language VMs Outline Motivation What is the need for HLL VMs? How are these different from System or Process VMs? Approach to HLL VMs Evolutionary history Pascal P-code Object oriented HLL VMs
Turning proof assistants into programming assistants
Turning proof assistants into programming assistants ST Winter Meeting, 3 Feb 2015 Magnus Myréen Why? Why combine proof- and programming assistants? Why proofs? Testing cannot show absence of bugs. Some
Breeze: A Language For Writing Secure Software. Cătălin Hriţcu
Breeze: A Language For Writing Secure Software Cătălin Hriţcu The SAFE team May 2011 @ San Jose: Sumit Ray, Howard Reubenstein, Andrew Sutherland, Tom Knight, Olin Shivers, Benjamin Pierce, Ben Karel,
Matching Logic. Grigore Rosu University of Illinois at Urbana-Champaign
Matching Logic Grigore Rosu University of Illinois at Urbana-Champaign Joint work with Andrei Stefanescu and Chucky Ellison. Started with Wolfram Schulte at Microsoft Research in 2009 Question could it
Verasco: a Formally Verified C Static Analyzer
Verasco: a Formally Verified C Static Analyzer Jacques-Henri Jourdan Joint work with: Vincent Laporte, Sandrine Blazy, Xavier Leroy, David Pichardie,... June 13, 2017, Montpellier GdR GPL thesis prize
Information Extraction from Real-time Applications at Run Time
1 Information Extraction from Real-time Applications at Run Time Sebastian Fischmeister University of Waterloo esg.uwaterloo.ca 2 Outline Setting the stage Motivate the need for information extraction
CMPSC 497 Buffer Overflow Vulnerabilities
Systems and Internet Infrastructure Security Network and Security Research Center Department of Computer Science and Engineering Pennsylvania State University, University Park PA CMPSC 497 Buffer Overflow
New programming language introduced by Microsoft contained in its.net technology Uses many of the best features of C++, Java, Visual Basic, and other
C#.NET? New programming language introduced by Microsoft contained in its.net technology Uses many of the best features of C++, Java, Visual Basic, and other OO languages. Small learning curve from either
Inference of Memory Bounds
Research Review 2017 Will Klieber, software security researcher Joint work with Will Snavely public release and unlimited distribution. 1 Copyright 2017 Carnegie Mellon University. All Rights Reserved.
Formal verification of an optimizing compiler
Formal verification of an optimizing compiler Xavier Leroy INRIA Rocquencourt RTA 2007 X. Leroy (INRIA) Formal compiler verification RTA 2007 1 / 58 The compilation process General definition: any automatic
CS558 Programming Languages
CS558 Programming Languages Fall 2017 Lecture 3a Andrew Tolmach Portland State University 1994-2017 Binding, Scope, Storage Part of being a high-level language is letting the programmer name things: variables
Applications. Cloud. See voting example (DC Internet voting pilot) Select * from userinfo WHERE id = %%% (variable)
Software Security Requirements General Methodologies Hardware Firmware Software Protocols Procedure s Applications OS Cloud Attack Trees is one of the inside requirement 1. Attacks 2. Evaluation 3. Mitigation
Rethinking the Memory Hierarchy for Modern Languages. Po-An Tsai, Yee Ling Gan, and Daniel Sanchez
Rethinking the Memory Hierarchy for Modern Languages Po-An Tsai, Yee Ling Gan, and Daniel Sanchez Memory systems expose an inexpressive interface 2 Memory systems expose an inexpressive interface Flat
The role of semantic analysis in a compiler
Semantic Analysis Outline The role of semantic analysis in a compiler A laundry list of tasks Scope Static vs. Dynamic scoping Implementation: symbol tables Types Static analyses that detect type errors
CSCI-GA Scripting Languages
CSCI-GA.3033.003 Scripting Languages 12/02/2013 OCaml 1 Acknowledgement The material on these slides is based on notes provided by Dexter Kozen. 2 About OCaml A functional programming language All computation
CS143 Final Spring 2016
CS143 Final Spring 2016 Please read all instructions (including these) carefully. There are 5 questions on the exam, all with multiple parts. This exam is designed to take 2 hours, but you have the full
SE352b: Roadmap. SE352b Software Engineering Design Tools. W3: Programming Paradigms
SE352b Software Engineering Design Tools W3: Programming Paradigms Feb. 3, 2005 SE352b, ECE,UWO, Hamada Ghenniwa SE352b: Roadmap CASE Tools: Introduction System Programming Tools Programming Paradigms
Agenda. CSE P 501 Compilers. Java Implementation Overview. JVM Architecture. JVM Runtime Data Areas (1) JVM Data Types. CSE P 501 Su04 T-1
Agenda CSE P 501 Compilers Java Implementation JVMs, JITs &c Hal Perkins Summer 2004 Java virtual machine architecture.class files Class loading Execution engines Interpreters & JITs various strategies
Singularity Reviewed an Operating System Challenging Common Concepts
an Operating System Challenging Common Concepts by Lothar Schäfer lothar.schaefer@sbg.ac.at Overview Singularity is a research operating system at Microsoft Research. The project started in 2003 and is
Buffer Overflow Defenses
Buffer Overflow Defenses Some examples, pros, and cons of various defenses against buffer overflows. Caveats: 1. Not intended to be a complete list of products that defend against buffer overflows. 2.
Testing. ECE/CS 5780/6780: Embedded System Design. Why is testing so hard? Why do testing?
Testing ECE/CS 5780/6780: Embedded System Design Scott R. Little Lecture 24: Introduction to Software Testing and Verification What is software testing? Running a program in order to find bugs (faults,
Analyzing Real-Time Systems
Analyzing Real-Time Systems Reference: Burns and Wellings, Real-Time Systems and Programming Languages 17-654/17-754: Analysis of Software Artifacts Jonathan Aldrich Real-Time Systems Definition Any system
Static Use-Based Object Confinement. Christian Skalka and Scott Smith The Johns Hopkins University
Static Use-Based Object Confinement Christian Skalka and Scott Smith The Johns Hopkins University Object confinement: what is it? Object confinement is concerned with the encapsulation, or protection,
Spot: A Programming Language for Verified Flight Software
Spot: A Programming Language for Verified Flight Software Rob Bocchino (bocchino@jpl.nasa.gov) Ed Gamble (ed.gamble@jpl.nasa.gov) Kim Gostelow Jet Propulsion Laboratory Califor nia Institute of Technology
Typed Assembly Language for Implementing OS Kernels in SMP/Multi-Core Environments with Interrupts
Typed Assembly Language for Implementing OS Kernels in SMP/Multi-Core Environments with Interrupts Toshiyuki Maeda and Akinori Yonezawa University of Tokyo Quiz [Environment] CPU: Intel Xeon X5570 (2.93GHz)
Semantic Analysis. Outline. The role of semantic analysis in a compiler. Scope. Types. Where we are. The Compiler so far
Outline Semantic Analysis The role of semantic analysis in a compiler A laundry list of tasks Scope Static vs. Dynamic scoping Implementation: symbol tables Types Statically vs. Dynamically typed languages
G Programming Languages - Fall 2012
G22.2110-003 Programming Languages - Fall 2012 Lecture 4 Thomas Wies New York University Review Last week Control Structures Selection Loops Adding Invariants Outline Subprograms Calling Sequences Parameter
CS 374 Fall 2014 Homework 2 Due Tuesday, September 16, 2014 at noon
CS 374 Fall 2014 Homework 2 Due Tuesday, September 16, 2014 at noon Groups of up to three students may submit common solutions for each problem in this homework and in all future homeworks You are responsible
Securing Software Applications Using Dynamic Dataflow Analysis. OWASP June 16, The OWASP Foundation
Securing Software Applications Using Dynamic Dataflow Analysis Steve Cook OWASP June 16, 2010 0 Southwest Research Institute scook@swri.org (210) 522-6322 Copyright The OWASP Foundation Permission is granted
Information Flow Analysis and Type Systems for Secure C Language (VITC Project) Jun FURUSE. The University of Tokyo
Information Flow Analysis and Type Systems for Secure C Language (VITC Project) Jun FURUSE The University of Tokyo furuse@yl.is.s.u-tokyo.ac.jp e-society MEXT project toward secure and reliable software
Run-time Environments - 3
Run-time Environments - 3 Y.N. Srikant Computer Science and Automation Indian Institute of Science Bangalore 560 012 NPTEL Course on Principles of Compiler Design Outline of the Lecture n What is run-time
Verified Characteristic Formulae for CakeML. Armaël Guéneau, Magnus O. Myreen, Ramana Kumar, Michael Norrish April 27, 2017
Verified Characteristic Formulae for CakeML Armaël Guéneau, Magnus O. Myreen, Ramana Kumar, Michael Norrish April 27, 2017 Goal: write programs in a high-level (ML-style) language, prove them correct interactively,
Static and User-Extensible Proof Checking. Antonis Stampoulis Zhong Shao Yale University POPL 2012
Static and User-Extensible Proof Checking Antonis Stampoulis Zhong Shao Yale University POPL 2012 Proof assistants are becoming popular in our community CompCert [Leroy et al.] sel4 [Klein et al.] Four-color
Shuffler: Fast and Deployable Continuous Code Re-Randomization
Shuffler: Fast and Deployable Continuous Code Re-Randomization David Williams-King, Graham Gobieski, Kent Williams-King, James P. Blake, Xinhao Yuan, Patrick Colp, Michelle Zheng, Vasileios P. Kemerlis,
Protecting Users by Confining JavaScript with COWL
Protecting Users by Confining JavaScript with COWL Deian Stefan, Edward Z. Yang, Petr Marchenko, Alejandro Russo, Dave Herman, Brad Karp, David Mazières The Web No longer just a way of publishing static
Semantic Analysis. Outline. The role of semantic analysis in a compiler. Scope. Types. Where we are. The Compiler Front-End
Outline Semantic Analysis The role of semantic analysis in a compiler A laundry list of tasks Scope Static vs. Dynamic scoping Implementation: symbol tables Types Static analyses that detect type errors
Static Use Based Object Confinement. Christian Skalka and Scott Smith The Johns Hopkins University
Static Use Based Object Confinement Christian Skalka and Scott Smith The Johns Hopkins University Object confinement: what is it? Object confinement is concerned with the encapsulation, or protection,
Practical Memory Safety with REST
Practical Memory Safety with REST KANAD SINHA & SIMHA SETHUMADHAVAN COLUMBIA UNIVERSITY Is memory safety relevant? In 2017, 55% of remote-code execution causing bugs in Microsoft due to memory errors Is
CSE 153 Design of Operating Systems
CSE 153 Design of Operating Systems Winter 19 Lecture 7/8: Synchronization (1) Administrivia How is Lab going? Be prepared with questions for this weeks Lab My impression from TAs is that you are on track
Resilient IoT Security: The end of flat security models
Resilient IoT Security: The end of flat security models Xiao Sun Senior Application Engineer ARM Tech Symposia China 2015 November 2015 Evolution from M2M to IoT M2M Silos of Things Standards Security
CSE P 501 Compilers. Java Implementation JVMs, JITs &c Hal Perkins Winter /11/ Hal Perkins & UW CSE V-1
CSE P 501 Compilers Java Implementation JVMs, JITs &c Hal Perkins Winter 2008 3/11/2008 2002-08 Hal Perkins & UW CSE V-1 Agenda Java virtual machine architecture.class files Class loading Execution engines
Modern Buffer Overflow Prevention Techniques: How they work and why they don t
Modern Buffer Overflow Prevention Techniques: How they work and why they don t Russ Osborn CS182 JT 4/13/2006 1 In the past 10 years, computer viruses have been a growing problem. In 1995, there were approximately
Comp 311 Principles of Programming Languages Lecture 21 Semantics of OO Languages. Corky Cartwright Mathias Ricken October 20, 2010
Comp 311 Principles of Programming Languages Lecture 21 Semantics of OO Languages Corky Cartwright Mathias Ricken October 20, 2010 Overview I In OO languages, data values (except for designated non-oo
Formal methods for software security
Formal methods for software security Thomas Jensen, INRIA Forum "Méthodes formelles" Toulouse, 31 January 2017 Formal methods for software security Formal methods for software security Confidentiality
Runtime. The optimized program is ready to run What sorts of facilities are available at runtime
Runtime The optimized program is ready to run What sorts of facilities are available at runtime Compiler Passes Analysis of input program (front-end) character stream Lexical Analysis token stream Syntactic
IS THERE A HOLE IN YOUR RISC-V SECURITY STACK? JOTHY ROSENBERG DOVER MICROSYSTEMS
IS THERE A HOLE IN YOUR RISC-V SECURITY STACK? JOTHY ROSENBERG DOVER MICROSYSTEMS I understand the difference in destruction is dramatic, but this has a whiff of August 1945. Someone just used a new weapon,