Software Security: A call to action

1. Software Security:A call to action From Jeanette Wing IEEE Security and Privacy 2003

2. Attacks • Today: code-level attacks, like buffer overflows. • Tomorrow? Attacks are increasingly more sophisticated. • If the defense gets better, the attackers get better. • Rather than reacting to attacks, let’s avoid the vulnerabilities in the first place. • Security by software design • Other important topics: usability, privacy and others

3. Call to arms to the Software Engineering Community • Must revisit all phases of the software development life cycle: requirements, design, testing, validation, maintenance. • Benefits of looking at design and security: • Learn about attacks at a system’s design and not just at the code level. • Generic design principles for security; maybe can find them also for other nonfunctional properties: usability, resource usage.

4. Toward compositional security • Exploiting vulnerabilities at the • Design and architectural levels • Design mismatches between a component and its operating environment (component makes assumptions beyond what environment can provide) • Data-structure and procedure-call levels • Example of Design Vulnerability: DNS spoofing attack

5. DNS spoofing attack • DNS: domain name server: maps names to a set of addresses. • Spoofing = faking the origin • Vulnerable component: browser • Environment: DNS infrastructure

6. DNS spoofing attack • Policy: An applet must connect to the same server from which it originated. • Netscape Navigator originally used two DNS name lookups.

7. Many-to-Many Relation: n2a IP addresses names One-to-many Many-to-one

8. DNS Spoofing Attack • X = name of the server from which the applet originated • Y = name of the server to which the applet wishes to connect • If n2a(X) intersect n2a(Y) is not empty then allow the connection.

9. Spoofing Attack IP addresses names x in n2a(X) X y in n2a(Y) Y Intersection check is too weak.

10. Spoofing Attack IP addresses names Store i i in n2a(Y) Y Better: store address i of originating server. i in n2a(Y)? is correct.

11. Vulnerability • At the design level. • Who to blame? • Netscape. • DNS infrastructure architecture. • Many-to-one function instead of relation? • Ambiguity of the specification: same server = same name or same IP address? • A compositional attack: browser made the wrong assumptions.

12. Emergent Abusive Behavior • Emergent behaviors • Flock of geese in V shape • Improvised Dance • Security: Denial of service attack (DOS): Repeat a single legitimate act over and over • Emergent structures • Any colony • Emergent systems • Stock market

13. DOS attack • Flood the receiving host • CERT/CC (SEI: coordination center for internet security expertise: Computer Emergency Readiness Team Coordination Center) • DOS attacks are on the rise (2003) and have surpassed buffer overflow attacks

14. Another example of emergent abusive behavior: Spam • Sending the same email a million times is abusive. • When is it abusive? 100, 1000, 10000, …

15. Emergent abusive behavior • Hard to define and detect. • Can be subjective.

16. General Framework for Compositional Security • M1 …Mn • + composition operator • ::= Satisfies relation • P: desired security property • M1 ::= P, … , Mn ::= P implies M1+…+Mn::=P

17. Compositional Security • M1 ::= P, … , Mn ::= P implies M1+…+Mn::=P • Vulnerability arises when the interfaces between any two components do not match, i.e., the two components do not compose according to the meaning of +. • Assumption made by one is not satisfied by the other. • DNS infrastructure and browser • Emergent abusive behavior: n too large, captured by P

18. Compositional Security • M1 ::= P, … , Mn ::= P implies M1+…+Mn::=P • Different kinds of +, ::=, P • Fixing + and ::= : For what kind of property does the formula hold? • Fixing ::= and P: For what kind of relaxed notion of composition can we gurantee the given property. • Components very flexible: small (class or procedure), large (browser or database), static (class interface), dynamic (procedure execution)

19. Compositional Security • M1 ::= P, … , Mn ::= P implies M1+…+Mn::=P • Security is a global property, but we build systems out of smaller pieces. Predicting the consequences of composing small pieces is hard.

20. Toward security design principles • Principle of least priviledge: only grant the minimum set of privileges required to perform an operation for the minimum time. • Privileges of accounts used during development • Priviledges of accounts used at runtime • Check preconditions.

21. Toward security design principles • Codify security principles • Static checks • Design patterns • Check lists

22. Usability • Security is only as strong as a system’s weakest link. • Usually: the system interacting with a human. • Good passwords • Hard-to-use user interfaces • Complicated installation and patch-management • Social engineering

23. Appeal to HCI community • Must design user interfaces that make security less obtrusive and less intrusive. • Ubiquitous computing: Must hide security from users but still provide them control. • Reduced susceptibility to social engineering attacks.

24. Privacy • “I believe that privacy is the next big area related to security for technologists to tackle.’’ • No consensus of what is privacy. • Which problems can be solved • Technically • Law and public policy

25. Privacy: technical viewpoint • Privacy = protecting people from unauthorized information uses. • Confidentiality = preventing unauthorized access to information = special case of privacy. • Analyzing information flow within a state machine system model or among program modules.

26. Privacy: technical viewpoint • X : nonpersonal; • Y : personal; • Z : sensitive; • X := Z ; // illegal • Promising, but limited.

27. Privacy • Software architectures and design principles. • Privacy in network protocols.

28. Privacy: conclusion • A lot of attention because of • Homeland security • Passenger screening • RFID tags • Identity theft • Electronic voting (society not yet willing to trust)

29. Context switch

30. Double-free vulnerability • Deallocate memory more than once. • Leads to heap corruption and crashing of the process or execution of arbitrary code. • Exploited via a malformed input to some function.

31. Switch • Other topics

32. Ravi’s proof for FPT • We consider cnf’s with at most k clauses. Call them All(k). • RED1(k): cnf’s with at most k clauses where each clause has length from 2 to k. • Reduction: A satisfiable cnf c1 in All(k) can be reduced to a satisfiable cnf c2 in RED1(k) so that a satisfying assignment for c2 results (in poly. time) in a satisfying assignment for c1.

33. Search tree • 2**(k**2) • Can we do it for SD or SAJ? • Cnf goes to expression and class graph. • At most k intersections corresponds to at most k clauses. Assume expression in normal form.

34. Related • The weight of a clause is 2**(-k) where k is the number of literals in the clause (=length). • The weight of a cnf is the the sum of the weight of its clauses. • Folklore: We can find an assignment in polynomial time that leaves at most the weight of the cnf unsatisfied.

35. Related • Assume all clauses have weight 2**(-y). • k*2**(-y) < 1 (The weight is less than 1, i.e., we can find a satisfying assignment in polynomial time.) • log k < y . So if we have k clauses of the same length, the length must be < log(k) otherwise the k clauses are satisfiable.