David Evans evans@cs.virginia cs.virginia/~evans

1. The Bugs and the Bees Research in Programming Languages and Security David Evans evans@cs.virginia.edu http://www.cs.virginia.edu/~evans University of Virginia Department of Computer Science

2. Computer Science • “How to” knowledge: • Ways of describing imperative processes (computations) • Ways of reasoning about (predicting) what imperative processes will do • Most interesting CS problems concern: • Better ways of describing computations • Ways of reasoning about what they do (and don’t do) David Evans - CS696

3. My Research Projects The Bugs – Splint The Bees - “Programming the Swarm” How can we detect code that describes unintended computations? How can we program massively distributed collections of simple devices and reason about their behavior in hostile environments? David Evans - CS696

4. A Gross Oversimplification all Formal Verifiers Bugs Detected Splint Compilers none Low Unfathomable Effort Required David Evans - CS696

5. (Almost) Everyone Likes Types • Easy to Understand • Easy to Use • Quickly Detect Many Programming Errors • Useful Documentation • …even though they are lots of work! • 1/4 of text of typical C program is for types David Evans - CS696

6. Limitations of Standard Types David Evans - CS696

7. Attributes Limitations of Standard Types David Evans - CS696

8. Approach • Programmers add annotations (formal specifications) • Simple and precise • Describe programmers intent: • Types, memory management, data hiding, aliasing, modification, null-ity, buffer sizes, security, etc. • Splint detects inconsistencies between annotations and code • Simple (fast!) dataflow analyses David Evans - CS696

9. Security Flaws 190 Vulnerabilities Only 4 having to do with crypto 108 of them could have been detected with simple static analyses! Reported flaws in Common Vulnerabilities and Exposures Database, Jan-Sep 2001. [Evans & Larochelle, IEEE Software, Jan 2002.] David Evans - CS696

10. Example: Buffer Overflows David Larochelle • Most commonly exploited security vulnerability • 1988 Internet Worm • Still the most common attack • Code Red exploited buffer overflow in IIS • >50% of CERT advisories, 23% of CVE entries in 2001 • Attributes describe sizes of allocated buffers • Heuristics for analyzing loops • Found several known and unknown buffer overflow vulnerabilities in wu-ftpd David Evans - CS696

11. Some Open Issues • Differential Program Analysis [Joel Winstead] • We usually don’t just have one program, we have lots of versions of similar programs • How can we discover interesting differences between two versions of a program? • e.g., find a test case that reveals the difference, find invariants that are different • Design-level Properties • Can we develop annotations and checks that deal with design-level properties? • Integrate run-time checking • Combine static and run-time checking to enable additional checking and completeness guarantees David Evans - CS696

12. Splint • More information: splint.org IEEE Software ’02, USENIX Security ’01, PLDI ’96 • Public release – real users, mentioned in C FAQ, C Unleashed, Linux Journal, etc. • Students (includes other PL/SE/security related projects): • David Larochelle: buffer overflows, automatic annotations • Joel Winstead: differential program analysis • Greg Yukl: source code generation • Current Funding: NASA (joint with John Knight) David Evans - CS696

13. Programming the Swarm David Evans - CS696

14. Really Brief History of Computer Science 1950s: Programming in the small... Programmable computers Learned the programming is hard Birth of higher-order languages Tools for reasoning about trivial programs 1970s: Programming in the large... Abstraction, objects Methodologies for development Tools for reasoning about component-based systems 2000s: Programming the Swarm! David Evans - CS696

15. What’s Changing • Execution Platforms • Small, cheap and unreliable • Limited power – communication is expensive • Execution environment • Interact with physical world • Unpredictable, dynamic • Programs • Old style of programming won’t work • Is there a new paradigm? David Evans - CS696

16. Programming the Swarm: Long-Range Goal Cement 10 GFlop David Evans - CS696

17. Why this Might be Possible? • We are surrounded by systems that: • Contain 50 Trillion (5 * 1013) components • Continue to function when 50 million components fail every second • Survive in hostile environments (even Canada!) • Self-organize starting from a single component and a program that is smaller than WindowsXP David Evans - CS696

18. A Biological Programming ModelSelvin George • Program systems the way biology does • Literal interpretation: • Cells can change state (genes turn on and off) • Cells can divide • Asymmetrically • Cells can communicate over short distances • Chemical diffusion David Evans - CS696

19. Example Cell Program state s1 { transitions -> (s1, s1) normal; } David Evans - CS696

20. Cell Programs • Use chemicals to control development • How can we produce cell programs that generate particular structures? • How can we reason about the behavior of cell programs in the presence of failures and randomness? • How can we describe cell programs at a higher level? (Making abstractions) David Evans - CS696

21. Less Literal Interpretation • Learn about self-organization and robustness by mimicking biology • Learn principles from biology, not programs • Use this to build real systems • Sensor networks • Distributed file sharing David Evans - CS696

22. Sensor Networks High-power base station Thousands of small, low-powered devices with sensors and actuators, communicating wirelessly David Evans - CS696

23. Sensor Networks High-power base station Compromised Node! Enemy base station David Evans - CS696

24. Security for Sensor Networks • Control Messages • Only messages from base station (or other nodes) should change device behavior • Data Collection • A few compromised nodes should not be able to prevent or tamper with data collection • Data Confidentially • Some applications: eavesdropper shouldn’t be able to interpret messages David Evans - CS696

25. Why security for sensor networks is hard • Low power devices • Cannot do traditional public-key algorithms • Limited device communication • Sending messages is extremely expensive • Communication is wireless • All messages are vulnerable to eavesdropping and forgery • Devices start identical – no stored secrets David Evans - CS696

26. Asymmetric Cryptography • Cryptography depends either on: • Shared secrets • Asymmetry (normally or information) • Exploit time and space asymmetries • Public-key systems get asymmetry by only one party knowing private key • In sensor networks, we can get asymmetry by using time (key is revealed later, but in a verifiable way) and space (only nodes within a certain distance can hear) David Evans - CS696

27. Non-Cryptographic Techniques • Redundancy • Lots of sensors, only a few will be compromised or bogus • Snooping • Because communication is wireless, nodes can hear what their neighbors are saying • If they are lying, tattle tale! David Evans - CS696

28. Programming the Swarm swarm.cs.virginia.edu • Students: • Selvin George: Biological Programming Model • Undergraduates: Keen Browne, Jacques Fournier, Chris Frost, Ami Malaviya, Jon McCune • Funding: NSF Career Award, NSF ITR David Evans - CS696

29. Summary • Programming the Swarm: Describing and reasoning about behavior of large ad hoc collections in hostile environments • Splint: Detecting differences between what programs express and what programmers intend • Be proactive about finding an advisor • Most important decision you will make in grad school • Matching process is last resort • Email to arrange meetings: evans@cs.virginia.edu David Evans - CS696