Microsoft Research
Directions in Security
Dieter Gollmann
Microsoft Research Cambridge
diego@microsoft.com
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
2
Microsoft Research
Agenda

Battling with spam
 Cryptographic
and visual puzzles
Secure software (briefly)
 Code based access control

 Stack

walks and beyond
The Millennium Bridge
3
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)

4
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!
5
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
6
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
7
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
8
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
9
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
10
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
11
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
12
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
13
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
14
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
15
Microsoft Research
Plain Access Control
verify the
parameters
If Safe(v) then …
carefully
chosen
interface
System
Trusted
prevented by scopes
& type safety
Applet
16
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
17
Microsoft Research
“Confused Deputy” Attacks
System
Trusted or
Applet ?
too late to
verify ?
Trusted
Applet
18
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
19
Microsoft Research
Runtime Permissions
check that
all callers
have FileIO
System
Trusted
Check FileIO
any code with FileIO
grant the static
permission “FileIO”
to trusted code
might forget
the callers
If Safe(v) then Grant FileIO
Applet
any code without FileIO
20
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);
…;
}
CODE
STACK
Main
g
f
21
Microsoft Research
Dynamic Stack Inspection
CODE
assembly C:\Foo.exe
Permissions: FileIO, …
void Main()
{
g(); …
}
assembly IE\Temp\Applet
Permissions: no FileIO, …
void g()
{
f(“password”);
}
assembly MSCorLib
Signature: …
Permissions: FileIO, …
void f(String s) {
File.Open(s);
…;
}
STACK
Main
g
f
Open
Check (FileIO)
Security
exception
22
Microsoft Research
Limits of Stack Inspection

Access control explained in terms of the runtime stack
for implementation reasons (lazy evaluation)



Two concerns for programmers:



Performance? Common optimizations are disabled
Security: What is guaranteed by stack inspection?
Hard to relate to high-level security policies
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
23
Microsoft Research
Example: Elimination of Tail Calls
void g()
{
…;
f(); // tail call
return;
}
void f() {
…;
}



f(…);
return;
…;
…;
With
tail call
elimination
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
24
Microsoft Research
Problems

Two interferences with
stack inspection:
 A untrusted
caller may
remove its tracks from
the stack.
…;
return f();
check p;…
check p;…
Proceeds
Security
exception
 A trusted
caller may
cancel an active grant
grant p;
return f();
check p;…
check p;…
Security
exception
Proceeds
25
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
26
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
27
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 PartiallyTrusted Code
28
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
29
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!
30