Towards Provably Secure and Correct Systems. Avik Chaudhuri

Size: px

Start display at page:

Download "Towards Provably Secure and Correct Systems. Avik Chaudhuri"

Antonia Riley
6 years ago
Views:

1 Towards Provably Secure and Correct Systems Avik Chaudhuri

2 Systems we rely on Opera<ng systems Storage systems Web applica<on frameworks Mobile device plaaorms Clouds These systems run our code. What security and correctness guarantees do they provide?

3 Aim of my research Develop founda:ons of secure and correct systems Analysis of systems (specifica4on + verifica4on) Construc<on of systems (design + implementa4on) Exploit programming languages as lens principles, techniques

4 This talk Overview of past and ongoing work on system analysis Storage systems (Plutus, OSD, PCFS) Opera4ng systems (Windows Vista, Asbestos) Mobile device plaforms (Android) Web applica4on frameworks (Ruby on Rails) Systems as programming languages Program analyses for system guarantees Similar ideas can guide system design

5 Analogy: Communica4on Model cryptography with equa<ons decrypt (encrypt (x, k), k) = x Programming language to describe protocols create new names (keys) build terms with func<on symbols (hashing, encryp4on) communicate terms over channels compose parallel processes [applied pi calculus]

6 Specifica4on and Verifica4on Adversary (arbitrary unspecified context) Language seman:cs defines the power of the adversary Specifica<on (types, logical asser<ons) Proof techniques (type systems, abstract interpreta<on) Tools (ProVerif, F7) Can verify protocols, their implementa:ons, and their uses This approach can be extended to other systems!

7 Storage systems Analysis of secure file sharing on untrusted storage [with B. Blanchet: S&P 08] various aoacks, precise guarantees Correct implementa<on of distributed access control [with M. Abadi: FMSE 05, FORTE 06; FCS 08] pifalls, general design principles Language support for proof carrying authoriza<on [with D. Garg: ESORICS 09] automa4c proof management

8 Opera4ng systems Analysis of opera<ng system security models [with S. Rajamani and others: CCS 08] decidability results, tool for system design Type system for enforcing security on an opera<ng system [with S. Rajamani and others: PLAS 08] formaliza4on of design inten4ons and best prac4ces

9 Mobile device plaforms Security verifica<on of mobile device applica<ons [PLAS 09; ongoing work with J. Foster and others] cer4fied installa4on with security guarantees

10 Web applica4on frameworks Security and correctness verifica<on of web applica<ons [with J. Foster and others: ASE 09, ongoing work] elimina4on of various classes of aoacks and bugs

11 Storage Reduc<onist: Storage is, arer all, communica<on write/read a file send/receive on a channel storage on untrusted disks communica4on over insecure networks Should be able to leverage previous work on communica:on Pragma<st: Careful! Why do we need dynamic access control? Expect dynamic specifica:ons (e.g., dynamic trust assump:ons)

12 Storage on Untrusted Disks Alice Bob Server: untrusted Clients: some trusted, some untrusted

13 Storage on Untrusted Disks Files: encrypted/signed Alice Bob Server: untrusted Clients: some trusted, some untrusted

14 Storage on Untrusted Disks Files: encrypted/signed Reader (knows read key) Alice Writer (knows write key) Bob Server: untrusted Clients: some trusted, some untrusted

15 Storage on Untrusted Disks Reader (knows read key) David Carol Alice Files: encrypted/signed Writer (knows write key) Eve Bob Server: untrusted Clients: some trusted, some untrusted

16 Storage on Untrusted Disks Reader (knows read key) Owner (creates/distributes keys) Writer (knows write key) David Eve Carol Alice Bob Files: encrypted/signed Server: untrusted Clients: some trusted, some untrusted

17 Storage on Untrusted Disks Reader David Alice Files: encrypted/signed Owner Writer Eve Carol Bob Server: untrusted Clients: some trusted, some untrusted

18 Storage on Untrusted Disks Reader (knows new read key) David Alice Files: encrypted/signed Owner (creates/distributes new keys) Writer (knows new write key) Eve Carol Bob Server: untrusted Clients: some trusted, some untrusted

19 Storage on Untrusted Disks David Files: encrypted/signed Reader Alice Owner Carol Writer Eve Bob Server: untrusted Clients: some trusted, some untrusted

20 Storage on Untrusted Disks David Files: encrypted/signed Reader (knows new read key) Alice Owner (creates/distributes new keys) Carol Writer (knows new write key) Eve Bob Server: untrusted Clients: some trusted, some untrusted

21 Op4miza4ons in Plutus Are files immediately re secured with new keys? No! Files secured with new keys on subsequent writes lazy revoca<on How do readers decide which keys to use? Throw away old keys, derive from new keys as required key rota<on Does the protocol implement these op4miza4ons correctly? What are the security implica4ons of these op4miza4ons?

secrecy than claimed writers can act for readers, secrets may eventually leak Serious axack

22 Specifica4on and Verifica4on Automated security analysis of Plutus with ProVerif applied pi calculus programs + expected proper<es Horn logic clauses + queries with Results Weaker secrecy than claimed writers can act for readers, secrets may eventually leak Serious axack on integrity (clever exploit of subtle bug) adversary can collude with readers to become writers

23 Key idea: Model Corrup4on Specify code for each role in the protocol owners trusted readers trusted or corrupt writers trusted or corrupt (trusted = follows protocol, corrupt = leaks keys) Adversary unspecified, controls any run of the protocol (e.g., chooses which principals to corrupt and when) Specify security despite corrup<on Security viola:on Precise lower bounds on corrup:on

Server Capability: unforgeable/verifiable authoriza<on

24 Distributed Access Control Networked Storage (e.g., OSD) Access Control Authority Client capability Disk Server Capability: unforgeable/verifiable authoriza<on cer4ficate Revoca:on is tricky How do we specify and verify correctness of implementa4ons?

25 Implementa4on as Refinement Ideal Storage Client Access Control Authority + Disk Server Study preserva<on of trace proper<es, equivalences Results Various ways to break full abstrac:on Nevertheless, correct implementa<ons exist with General design principles: Distributed implementa:on of stateful computa:ons

System File system requires authoriza<on

with PCAL: Language/compiler support for

manages proofs & instruments script Tricky!

26 Proof Carrying Authoriza4on Distributed Access Control Authori4es Client File System File system requires authoriza<on proofs Tremendous burden on user Solu<on with PCAL: Language/compiler support for PCA systems user writes script, compiler manages proofs & instruments script Tricky! (e.g., proofs at compile 4me may be invalid at run 4me)

27 Opera4ng Systems Various levels of trust (ordered) Process Loca4on System Admin User Web Protec<on mechanisms (e.g., labels for access control) intend to restrict informa:on flow across levels of trust but oaen do not! (too restric4ve)

28 Access Control for Integrity no write up no execute down Browser security Web data cannot overwrite User loca4on Web code cannot be run by Admin process Browser func:onality? User needs to download data from Web (e.g., aoachment) Admin needs to install code from Web (e.g., game applica4on)

29 Dynamic Control of Labels Windows Vista Process Loca4on Admin can install code from Web User can save data from Web spawn untrusted process (execute less trusted code) trust untrusted loca4on (verify trust by other means) read untrusted loca4on (only overwrite untrusted data)

Dynamic Control of Labels Windows Vista Process Loca4on Admin can install code from Web User can save data from Web spawn untrusted process (execute less trusted code) trust untrusted

30 Dynamic Control of Labels Windows Vista Process Loca4on Admin can install code from Web User can save data from Web spawn untrusted process (execute less trusted code) trust untrusted loca4on (verify trust by other means) Implicit design inten:ons, best prac:ces? (Similar ideas in other opera4ng systems, e.g., Asbestos) read untrusted loca4on (only overwrite untrusted data)

31 Specifica4on and Verifica4on System Designer: What guarantees can the system provide? model behaviors (dynamic seman4cs) analyze restric<ons (sta4c seman4cs) ProVerif undecidable query evalua:on can be a problem! Solu<on Eon: dynamic logic programming expressive enough decidable query evalua:on with

32 Eon Eon = Datalog + new + next + some syntac4c restric4ons (unary dynamic predicates, monotonicity) new: create constants ini4alized with some predicates next: update predicates for such constants Datalog: enforce constraints Query evalua:on: reduc:on to Datalog query sa:sfiability (new = existen<al quan<fier, next = state transformer)

33 Automated Analysis with Eon Experiments model behaviors (dynamic seman4cs) analyze restric<ons (sta4c seman4cs) Results Windows Vista Adacks can be blamed on trusted processes (interes4ng design principle) Sound monitoring of trusted processes to eliminate adacks Explicit design inten4ons, best prac4ces!

34 Code Analysis for Security Windows Vista AOacks can be eliminated by restric4ng trusted code Idea Enforce restric:ons on code via a security type system types = security invariants soundness = type preserva<on with

35 Access Control + Security Types Programming language to describe code running on system create processes/loca<ons that are protected with labels update labels (access control) pack code as data (compila4on) read/write/execute contents at loca4ons Access control encoded in dynamic seman<cs Security types enforce sta<c seman<cs Hybrid typechecking (soundness, precision, op4miza4on)

36 Access Control + Security Types Security type T L (data of type T, trusted sta<cally at level L) Type Loc T L (loca<on that contains data of security type T L ) If loc : Loc T L, then dynamic label of loc L By access control, levels < L cannot write to loc control dynamic label of loc By typechecking, ensure that levels L always write data that flows from levels L to loc maintain dynamic label of loc L

37 Examples [System] [User] [Web] ini4alize cmd.exe ini4alize url ie.exe contains code: reads url & executes contents executes ie.exe at Web virus.exe contains code: overwrites cmd.exe url contains virus.exe Code typechecks [Web cannot write to cmd.exe]

38 Examples [System] [Admin] [User] [Web] ini4alize home ini4alize url ini4alize setup.exe ie.exe contains code: reads url & copies contents to setup.exe trusts setup.exe & executes it executes ie.exe at Web virus.exe contains code: overwrites home url contains virus.exe Code does not typecheck [Admin can write to home]

controlled sta<cally (at install 4me) app store Can Alice know whether

39 Mobile Device PlaForms Android opera4ng system + core apps SDK: Java APIs to develop new apps Alice (user) Apps can share components Sharing controlled sta<cally (at install 4me) app store Can Alice know whether Bob s app is safe? Can Bob convince Alice that the app is safe? Bob (developer)

40 Cer4fied Installa4on (PCC) Bob constructs a proof that his app is safe Alice verifies the proof before installing the app (proofs may be implemented as cer<ficates) Requirements Opera<onal seman<cs for apps running on Android formal specifica<ons of APIs provided by SDK Separate verifica:on of APIs for efficiency Sta<c analysis of Android apps for safety formalized as a security type system Soundness of analysis provides necessary proofs

41 Android Applica4ons code may belong to other apps run with permissions of those apps components inherited classes, overridden methods pool of listeners manifest declare necessary permissions specify access controls for other apps stack of windows data sta<c dynamic

42 Sta4c Analysis with concrete code [Java] abstract code (typecheck) Security specifica<ons derived from manifests of installed apps Typechecking guarantees that access controls enforce security Suppose that reading my contacts list requires permission P Then only apps installed with permission P can know my contacts Droid: cer<fied installer for Android apps (in progress)

Web Applica4on Frameworks Ruby on Rails Ruby: dynamically typed OO scrip<ng language Rails: Ruby APIs for automa<ng development of web apps Models, Views, Controllers models

43 Web Applica4on Frameworks Ruby on Rails Ruby: dynamically typed OO scrip<ng language Rails: Ruby APIs for automa<ng development of web apps Models, Views, Controllers models connected to database tables views described by code embedded markup controllers route requests to responses Conven:on over Configura:on request response controllers models views database

Sta4c Analysis Rails makes extensive use of meta programming in Ruby Direct analysis is difficult DRails: translate to explicit Ruby code that is easier to analyze concrete code [Ruby on Rails]

44 Sta4c Analysis Rails makes extensive use of meta programming in Ruby Direct analysis is difficult DRails: translate to explicit Ruby code that is easier to analyze concrete code [Ruby on Rails] translated code [Ruby] (typecheck) [DRuby] with Typechecking guarantees that method calls succeed But almost everything is a method call in Ruby! Results Bugs that crash exis4ng apps (confirmed by developers)

45 Sta4c Analysis with concrete code [Ruby on Rails] translated code [Ruby] (execute and verify) Simple typechecking cannot catch logical errors/security aoacks Advanced type systems difficult to build for Ruby Rubyx: symbolic verifica<on of Ruby scripts (in progress) Key idea: executable specifica<ons

46 Systems of the Future Influence of programming languages Principles Core, expressive abstrac4ons Strong guarantees of security and correctness Implementa4ons as refinements Techniques Rich types/invariants for specifica4on and verifica4on Combina4ons of sta4c and dynamic mechanisms

47 Systems of the Future Influence of programming languages Revisit academic programming languages strong founda4ons reduce complexity, spur inven4ons View system design as language design generaliza4ons provide insight, set trends Opportunity to make las:ng contribu:ons

Language-Based Security on Android (call for participation) Avik Chaudhuri

+ Language-Based Security on Android (call for participation) Avik Chaudhuri + What is Android? Open-source platform for mobile devices Designed to be a complete software stack Operating system Middleware