wyvern designing a language for security
play

Wyvern: Designing a Language for Security Jonathan Aldrich - PowerPoint PPT Presentation

Wyvern: Designing a Language for Security Jonathan Aldrich contributions from: Aaron Craig aldrich@cs.cmu.edu Justin Lubin http://www.cs.cmu.edu/~aldrich/ Darya Melicher Cyrus Omar Alex Potanin Anlun Xu Valerie Zhao 17-396: Language


  1. Wyvern: Designing a Language for Security Jonathan Aldrich contributions from: Aaron Craig aldrich@cs.cmu.edu Justin Lubin http://www.cs.cmu.edu/~aldrich/ Darya Melicher Cyrus Omar Alex Potanin Anlun Xu Valerie Zhao 17-396: Language Design and Prototyping Spring 2020 School of Computer Science

  2. Software security is a big problem! Prototype pollution attack (lodash) lodash node module before 4.17.5 suffers from a Modification of Assumed-Immutable Data (MAID) vulnerability via defaultsDeep, … The 10 Worst Security Vulnerabilities of 2018 #3: The pdfinfojs NPM module for versions <= October 17, 2018 0.3.6 allows for command injection, allowing an attacker to execute arbitrary commands to the Security flaw in libssh leaves machine. thousands of servers at risk of hijacking 2

  3. Why Systems are Vulnerable? • We “know” how to code securely • Follow the rules: CERT, Oracle, … • Technical advances: type, memory safety • But we still fail too often! • Root causes • Coding instead of engineering • Human limitations • Unusable tools 3

  4. Our Approach: Usable Architecture-Based Security Outline – 3 issues Engineering: Usability: • Tampering w/mutable data An architecture/design A human  Immutability perspective perspective • Command injection  Type-specific languages • Resource use  Capabilities and effects Secure systems development Settings • Java (some studies) • Wyvern , a programming language designed following these principles Formal modeling: A mathematical perspective Bridge icon credit: iconsmind.com Lock icon credit: Appzgear at flaticon.com Wyvern credit: Zigeuner 4

  5. Immutability: An Architectural Perspective • Architecture: “the set of principal design decisions about the system” [Garlan and Shaw 1996; Taylor et al. 2009] • Typically large in scope • Non-architectural • final in Java: one field only, non-transitive • const in C++: protects through one reference only • Both weak reasoning: partial protection of data structure • Architectural • Transitive immutability : entire data structure protected • Strong reasoning – for security, concurrency, etc. • Interview studies: programmers want guarantees that only transitive immutability can provide [Coblenz et al. ICSE 2017] 5

  6. Formal modeling: enforcing immutability • How to enforce transitive immutability, technically? • Design decisions based on type systems / soundness proofs Static semantics Formal grammar Dynamic semantics 6

  7. Usability Experiments • 20 experienced Java programmers, 10 each in Java and Glacier • Compared errors/vulnerabilities and completion rates (Java  Glacier) errors completion 10  0 10  7 Enforcing immutability FileRequest.execute() security task 4  0 8  8 7  0 10  7 HashBucket.put() task • Unsuprising: no errors in Glacier condition • Surprising (perhaps): Glacier didn’t slow people down much • Usability results still uncommon for type systems • We should do more! 7

  8. Wyvern • Design goals • Sound, modern language design • Type- and memory-safe, mostly functional, advanced module system • Incorporate usability principles [Coblenz et al. Onward! 2018] • Security mechanisms built in • E.g. cleaner than Glacier retrofit to Java Discuss: how is immutability cleaner in Wyvern than in Glacier? • Immutability support • Default: transitive immutability • resource indicates types abstracting OS resources or mutable state Demo: Immutability in Wyvern (examples/types/person.wyv) http://wyvernlang.github.io/ 8

  9. Our Approach: Usable Architecture-Based Security Outline – 3 issues Engineering: Usability: • Tampering w/mutable data Transitive immutability Simple design,  Immutability has architectural benefits experimentally • Command injection proven effective  Type-specific languages • Resource use  Capabilities and effects Immutability in Wyvern Settings • Java (some studies) • Wyvern , a programming language designed following these principles Formal modeling: Proof of transitive immutability 9

  10. SQL Command Injection Example credit XKCD: HTTP :// XKCD . COM /327/ String s = "SELECT * FROM Students WHERE name ='" + studentName + "';" Now plug in the name: Robert'; DROP TABLE Students; -- "SELECT * FROM Students WHERE name ='Robert'; DROP TABLE Students; --';" Many similar issues • HTML (cross-site scripting) The data now includes an • Shell scripts (command injected SQL command injection) • … 10

  11. SQL Injection: a Solved Problem? Prepare a statement PreparedStatement s = connection.prepareStatement( with a hole "SELECT * FROM Students WHERE name = ?;"); s.setString(1, userName); Fill the hole s.executeQuery(); securely Discuss: why might this solution be less than satisfactory? • Evaluation X • Usability: unnatural, verbose X • Design: string manipulation captures domain poorly X • Language semantics: largely lost – just strings • No typechecking, IDE services, … 11

  12. Wyvern: Usable Secure Programming ~ introduces a domain- • A SQL query in Wyvern specific language (DSL) on the next indented lines connection.executeQuery(~) SELECT * FROM Students WHERE name = {studentName} Semantically rich DSL. Safely incorporates Can provide typchecking, dynamic data—as data, syntax highlighting, not a command …autocomplete, … • Hypothesis: Wyvern version more natural and more usable • No empirical evaluation, yet • But Omar et al. [ICSE 2012] shows benefits of similar DSL IDE plugins 12

  13. Technical Challenge: Syntax Conflicts • Language extensions as libraries has been tried before • Example: SugarJ/Sugar* [Erdweg et al, 2010; 2013] import XML, HTML Is it XML or HTML? val snippet = ~ How do I <b> parse </b> this example? 13

  14. Syntax Conflicts: Wyvern’s Solution metadata keyword indicates import metadata XML, HTML we are importing syntax, not just a library val snippet : XML = ~ How do I <b> parse </b> this example? No ambiguity: the compiler loads the unique parser associated with the expected type XML Syntax of language completely unrestricted – indentation separates from host language 14

  15. Thinking About Wyvern’s Solution import metadata XML, HTML, SQL val snippet : XML = ~ How do I <b> parse </b> this example? connection.executeQuery(~) SELECT * FROM Students WHERE name = {studentName} Discuss: what might be possible downsides of this design? 15

  16. Technical Challenge: Semantics Q: Is it safe to run custom parser at compile time? A: Yes – immutability types used to ensure imported metadata is purely functional, has no network access, etc. import metadata SQL Language definition includes val connection = SQL.connect(…) custom typechecker – can verify val studentName = input(…) query against database schema connection.executeQuery(~) SELECT * FROM Students WHERE name = {studentName} Splicing theory ensures capture- avoiding substitution in code SQL extension has access to generated by SQL extension – safe variables and their types in to use host language variables Wyvern host language 16

  17. Wyvern demo • wyvern/examples/tsls • formatstringClient.wyv (format strings) • postfixClient.wyv (list and postfix arithmetic) 17

  18. Our Approach: Usable Architecture-Based Security Outline – 3 issues Engineering: Usability: • Tampering w/mutable data Express design in Natural syntax,  Immutability domain-specific way enabling IDE • Command injection suppoert  Domain-specific languages • Resource use  Capabilities and effects DSL support in Wyvern Settings • Java (some studies) • Wyvern , a programming language designed following these principles Formal modeling: Type safety, variable hygiene, conflict-free extensions 18

  19. Resource Use • SQL extensions are nice! • But what if people use a low-level, string-based library anyway? • More broadly, what if people misuse resource-access libraries? 19

  20. What might code do to system resources? • Example scenario: constraining plugins Are these plugins safe? Could a malicious plugin delete my files? 20

  21. What might code do to system resources? • What can a plugin do? • File reads, writes? • Log an error message? • Like a file write, but more abstract Plugin My app 21

  22. What might code do to system resources? • Goal: enforce architectural layering [Dijkstra 1968] • Application code gets data using a Application code • Query ADT , which is implemented via a • SQL library , which sends commands via a • Network driver , which talks to database Query ADT • Security constraints • Network used only for database queries String-based • No direct use of string-based SQL library SQL library • Possible command injection • Abstraction of system resources • Application does safe queries Network • Query ADT does unsafe queries driver • Network driver does network access 22

  23. Two views of the resource use problem How to reason formally about resource use? How to practically enforce resource use? Can we be just as lightweight as the practical approach, but retain formal reasoning ? 23

  24. Formalist: Let’s check this statically! An effect system sounds like a good idea! 24

Recommend


More recommend