Software Security:A call to action

From Jeanette WingIEEE Security and Privacy 2003

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

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.

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

DNS spoofing attack

• DNS: domain name server: maps names to a set of addresses.

• Spoofing = faking the origin• Vulnerable component: browser• Environment: DNS infrastructure

DNS spoofing attack

• Policy: An applet must connect to the same server from which it originated.

• Netscape Navigator originally used two DNS name lookups.

Many-to-Many Relation: n2a

names IP addresses

One-to-many

Many-to-one

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.

Spoofing Attack

names IP addresses

X

Y

x in n2a(X)

y in n2a(Y)

Intersection checkis too weak.

Spoofing Attack

names IP addresses

Y

Store i

i in n2a(Y)

Better: store address i of originating server.i in n2a(Y)? is correct.

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.

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

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

Another example of emergent abusive behavior: Spam

• Sending the same email a million times is abusive.

• When is it abusive? 100, 1000, 10000, …

Emergent abusive behavior

• Hard to define and detect.• Can be subjective.

General Framework for Compositional Security

• M1 …Mn • + composition operator• ::= Satisfies relation• P: desired security property• M1 ::= P, … , Mn ::= P implies M1+…

+Mn::=P

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

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)

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.

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.

Toward security design principles

• Codify security principles– Static checks– Design patterns– Check lists

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

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.

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

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.

Privacy: technical viewpoint

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

Privacy

• Software architectures and design principles.

• Privacy in network protocols.

Privacy: conclusion

• A lot of attention because of– Homeland security– Passenger screening– RFID tags– Identity theft– Electronic voting (society not yet willing to

trust)

Context switch

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.

Switch

• Other topics

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.

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.

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.

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.