Nireshen Beerbul Senior Consultant Microsoft [email protected].
Microsoft Research Directions in Security Dieter Gollmann Microsoft Research Cambridge...
-
Upload
oscar-neal -
Category
Documents
-
view
217 -
download
2
Transcript of Microsoft Research Directions in Security Dieter Gollmann Microsoft Research Cambridge...
Microsoft Research
Directions in Security
Dieter Gollmann
Microsoft Research Cambridge
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!