Microsoft Research Directions in Security Dieter Gollmann Microsoft Research Cambridge [email protected].

Microsoft Research

Directions in Security

Dieter Gollmann

Microsoft Research Cambridge

[email protected]

2

Microsoft Research

Security and the Internet

The Internet has been a major force in driving Information Security

Throughout the 1990s the focus was on communications security: SSL/TLS, IPSec

Communications security is comparatively “easy” We are left with the difficult problems: keeping

rogue users in check and securing complex end systems

3

Microsoft Research

Agenda

Battling with spamCryptographic and visual puzzles

Secure software (briefly) Code based access control

Stack walks and beyond The Millennium Bridge

4

Microsoft Research

Battling with spam

Spam has become a major nuisance Extreme? 5,000 spam messages per day

(Richard Clayton, Cambridge University) Unsolicited mass mailings are not a new

problem Spam filters: rule-based message blocking Legislation: EC Directive 2002/58/EC,

some US states following suit (Virginia)

5

Microsoft Research

Make the sender work Cryptographic “puzzles”: sender asked to

perform a computation before mail is accepted Challenge: find the right computational problem

Spammers should not have easy time-memory tradeoffs

Regular users should not face an onerous burden Project at Microsoft Research, Silicon Valley

Martín Abadi, Mike Burrows, Mark Manasse, and Ted Wobber: Moderately Hard, Memory-bound Functions

Users must download software for solving the puzzles: management and security issue!

6

Microsoft Research

Make the sender work Stop automated generation of email accounts Visual “puzzles” that beat machines, linked to

research in artificial intelligence Research by MSR Redmond used by Hotmail:

When opening a new Hotmail account, a visual challenge has to be retyped in response

7

Microsoft Research

Secure Software Secure software can handle intentionally

malformed inputs: Don’t trust your inputs! Networking software is a popular target

intended to receive external input involves low level manipulations of buffers

Not software with security features Secure software has only recently become an

active research area: first books in 2001 A focus of Microsoft’s trustworthy computing

initiative

8

Microsoft Research

Secure Software

I will not talk about buffer overflows in detail For technical details on this and other issues

please refer to Michael Howard & David LeBlanc: Writing Secure

Code, Second Edition, Microsoft Press, 2002 John Viega & Gary McGraw: Building Secure

Software, Addison Wesley, 2001 I will sketch my view of the general nature of the

problem

9

Microsoft Research

Dangers of abstraction

Programmers use elementary concepts like character, variable, array, integer, data & program, address (resource locator), atomic transaction, …

These concepts have abstract meanings To execute a program, we need concrete

implementations of these abstract concepts Software security problems arise when concrete

implementation and abstract intuition diverge

10

Microsoft Research

Dangers of abstraction

Abstraction: For integers a, b 0: a + b a 32-bit INT: 0xFF00 + 0x0100 = 0x0000: a + b < a Ashcraft & Engler [IEEE S&P 2002]: “Many

programmers appear to view integers as having arbitrary precision, rather than being fixed-sized quantities operated on with modulo arithmetic.”

Abstraction: variables store arbitrary values Concrete implementation: a fixed buffer is

allocated; buffer overflows: the value assigned to a variable is too large for the buffer allocated

11

Microsoft Research

What to do?

Educate software developers Automated testing for known problem areas

PREfix and PREfast used in Microsoft Black-box testing is useful: You do not need the

source code to find out how a program works: execute it!

Hackers use tools to search for vulnerabilities; when you follow their strategies you have a chance to get good test coverage

12

Microsoft Research

What to do?

Type-safe languages avoid some of the problems (but not all)

Verification, useful as it is, can’t prove “security”: we prove security properties of abstract models; attackers will go outside the envelope side channel analysis of smart card crypto

Apply security patches: many attacks exploit known vulnerabilities where patches exist

The owner of the end system has to be a competent system manager

13

Microsoft Research

Access Control

Traditionally, computer systems were used in institutions and enterprises

Access control based on user identities keeps outsiders at bay: “principals are honest”

The institution has authority over its members Today, in e-commerce we want protection

against insider fraud: no “trust” in our partners There need not be a common (legal) authority Contemplate access control without user

identities

14

Microsoft Research

Code based access control

Alternative to identity-based access control; access decisions considering: site of code origin: local or remote? URL of code origin: intranet or Internet? code signature: signed by trusted author? code identity: approved (‘trusted’) code? code proof: code author provides proof of security

properties Code based (evidence based) access control in

Java security and .NET security

15

Microsoft Research

New challenges

How to enforce code based access control? Confused deputy problem Stack walks History based access control

How to manage code based access control? When code can assert access rights, an attacker can

gain more rights by running this code

16

Microsoft Research

Applet

System

Trusted

Plain Access Control

prevented by scopes & type safety

If Safe(v) then …

verify the parameters

carefully chosen

interface

17

Microsoft Research

Confused deputy problem

“Untrusted” code, more precisely code without some specific rights, calls “trusted” code, i.e. code with those specific rights

Confused deputy problem: the untrusted code “fools” the trusted code into performing an action that violates security

How to address this problem? This problem has been studied since the 1970s

18

Microsoft Research

Applet

System

Trusted

“Confused Deputy” Attacks

too late to verify ?

Trusted or Applet ?

19

Microsoft Research

Code-based access control

Access rights (permissions) allocated to pieces of code

Check that the caller’s allocated (granted) permissions match the required permissions

Keep track of the call chain to address the confused deputy problem

Favourite method for computing the current permissions: stack walking

20

Microsoft Research

Applet

System

any code with FileIO

If Safe(v) then Grant FileIO

Trusted

Runtime Permissions

any code without FileIO

Check FileIO

check that all callers

have FileIO

might forget the

callersgrant the static

permission “FileIO” to trusted code

21

Microsoft Research

The Call Stack (as usual)

At every function call a new frame is created on the stack

Each frame contains the local state of the function

void Main(){

g(); … }void g(){ …; f(“password”); …; }void f(String s) { File.Open(s); …;}

Main

CODE STACK

g

f

22

Microsoft Research

Dynamic Stack Inspectionassembly C:\Foo.exe

Permissions: FileIO, …void Main(){ g(); … }

assembly IE\Temp\AppletPermissions: no FileIO, …void g(){ f(“password”);}

assembly MSCorLibSignature: …Permissions: FileIO, …void f(String s) { File.Open(s); …;}

Securityexception

Main

g

f

CODE STACK

Check (FileIO)Open

23

Microsoft Research

Limits of Stack Inspection Access control explained in terms of the runtime stack

for implementation reasons (lazy evaluation) Performance? Common optimizations are disabled Security: What is guaranteed by stack inspection?

Hard to relate to high-level security policies

Two concerns for programmers: Untrusted component may take advantage of my code Permissions may be missing when running my code

Stack inspection is blind to many control and data flows Parameters, results, mutable data, objects, inheritance,

callbacks, events, exceptions, concurrency…

Each case requires a specific discipline or mechanism

24

Microsoft Research

Example: Elimination of Tail Calls

Once f() is called, we don’t need g’s frame anymore and can overwrite g’s frame with f’s new frame

Eventually, f returns directly to g’s caller An useful optimization for recursive programs

f(…); return;

… ;

… ;

void g(){ …; f(); // tail call return; }void f() { …;}

Withtail call

elimination

25

Microsoft Research

Problems Two interferences with

stack inspection:

A untrusted caller may remove its tracks from the stack.

A trusted caller may cancel an active grant

…; return f();

check p;…

check p;…

Securityexception

Proceeds

grant p; return f();

check p;…

check p;…

Securityexception

Proceeds

26

Microsoft Research

History-Based Access Control

Don’t be lazy, keep track of callers’ rights proactively

Static rights (S) associated with each piece of code at load time

Current rights (D) associated with each execution unit, updated automatically at execute time (D := D S)

Controlled modifications of current rights using “grant” and “accept” programming patterns

27

Microsoft Research

Managing access rights

Managing assignment: e.g. assign access rights to assemblies

Managing the effects of assignment: given a software configuration, What can a caller with given rights actually do? Which rights would give access to a given resource?

Related topics: API attacks on key management modules Privilege escalation

28

Microsoft Research

Further reading

Cédric Fournet, Andy Gordon: Stack Inspection: Theory and Variants

Cédric Fournet, Martín Abadi: Access Control Based on Execution History

Cédric Fournet, Andy Gordon, Martín Abadi, Tomasz Blanc: Access Control for Partially-Trusted Code

29

Microsoft Research

Conclusions

Security is changing because some fundamental assumptions about the environment are changing

Some established approaches to implementing security may no longer be appropriate

Some of the “new” challenges have been looked at decades ago

We are just starting to learn how to use code based access control: beyond the technicalities, a main challenge is to find good coding disciplines

30

Microsoft Research

Final message We are quite good at solving problems we

understand; these are the problems of the past but the world keeps changing

Software engineering is often compared unfavourably with bridge building

Millennium Bridge across the Thames: closed within two days, reopened after two years http://www.arup.com/millenniumbridge/ Synchronous Lateral Excitation

We are not alone!