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

2. 23 Sept 2002David Evans - CS6962 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)

3. 23 Sept 2002David Evans - CS6963 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?

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

5. 23 Sept 2002David Evans - CS6965 (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

6. 23 Sept 2002David Evans - CS6966 Limitations of Standard Types Type of reference never changes State changes along program paths Language defines checking rules System or programmer defines checking rules One type per reference Many attributes per reference

7. 23 Sept 2002David Evans - CS6967 Type of reference never changes State changes along program paths Language defines checking rules System or programmer defines checking rules One type per reference Many attributes per reference Attributes Limitations of Standard Types

8. 23 Sept 2002David Evans - CS6968 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

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

10. 23 Sept 2002David Evans - CS69610 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

11. 23 Sept 2002David Evans - CS69611 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

12. 23 Sept 2002David Evans - CS69612 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)

13. 23 Sept 2002David Evans - CS69613 Programming the Swarm

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

15. 23 Sept 2002David Evans - CS69615 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?

16. 23 Sept 2002David Evans - CS69616 Programming the Swarm: Long-Range Goal Cement 10 GFlop

17. 23 Sept 2002David Evans - CS69617 Why this Might be Possible? We are surrounded by systems that: –Contain 50 Trillion (5 * 10 13 ) 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

18. 23 Sept 2002David Evans - CS69618 A Biological Programming Model Selvin 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

19. 23 Sept 2002David Evans - CS69619 Example Cell Program state s1 { transitions -> (s1, s1) normal; }

20. 23 Sept 2002David Evans - CS69620 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)

21. 23 Sept 2002David Evans - CS69621 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

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

23. 23 Sept 2002David Evans - CS69623 Sensor Networks High-power base station Compromised Node! Enemy base station

24. 23 Sept 2002David Evans - CS69624 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

25. 23 Sept 2002David Evans - CS69625 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

26. 23 Sept 2002David Evans - CS69626 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)

27. 23 Sept 2002David Evans - CS69627 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!

28. 23 Sept 2002David Evans - CS69628 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

29. 23 Sept 2002David Evans - CS69629 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