Following the Collaborators' Workshop held on 26th Sept (presentations available on KTN's SlideShare account), EPSRC/ESRC are running a Collaboration Development workshop on 22nd November 2019 in London to facilitate academia-industry and academia-academia collaboration ahead of the closing dates for the EPSRC and ESRC ISCF Digital Security by Design calls. The calls need to be led by academic institutions. Industrial involvement, while not mandatory, is highly desirable and will be required for future competitions. Hence this workshop aims to have a mix of academic and industrial participants. The Digital Security by Design challenge was announced in July. This challenge, amounting to £70 million of government funding over 5 years, will be delivered by UK Research and Innovation (UKRI) through the Industrial Strategy Challenge Fund (ISCF). Find out more: https://ktn-uk.co.uk/news/iscf-digital-security-by-design-collaboration-development-workshop

1. Security and Legacy
at Microsoft
MATTHEW PARKINSON
PRINCIPAL RESEARCHER, CONFIDENTIAL COMPUTING, MICROSOFT
RESEARCH

2. Motivation
Microsoft cares about security
Microsoft cares about legacy

3. Fixing individual
bugs not scaling
130
109
141
163
234 224
155
305 317
474
417
603 600
2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018
#ofCVEs
Patch Year
# of CVEs by patch year

4. Microsoft cares about security
slide courtesy of Matt Miller, Partner Security Engineer, MSRC
32 24
21 22 26
13 4 11 4 1 3 7 8
36 35
43
45 64
30 36
35
28 61
71 104 79
12
16
18
22
44
57
39
113
186
183
87
81 99
4
4
13 30 21
14
7 15
25
25
36
71 81
6
4
8
8
11
6
5 6
9
22
19 82 61
1
1
2
4
9
5
7 13
17
39
76
88
55
44
30 44
41 59
103
61 120
59
159 139 197
221
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018
Root cause of CVEs by patch year
Stack Corruption Heap Corruption Use After Free Type Confusion Uninitialized Use Heap OOB Read Other
Top root causes since 2016:

5. What is Microsoft doing?
Remove classes of vulnerabilities
◦ Probabilistic prevention not considered suitable - servicing a vulnerability still required
◦ MemGC - https://msrc-blog.microsoft.com/2016/01/12/triaging-the-exploitability-of-ieedge-crashes/
◦ Killing Uninitialized Memory: Protecting the OS Without Destroying Performance -
https://cppcon2019.sched.com/event/SfYc/killing-uninitialized-memory-protecting-the-os-without-destroying-
performance
Investing in safe(r) systems programming languages:
◦ Rust investigations, https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/
◦ Project Verona, research project
◦ Cannot simply throw away old code!

6. Our research in Cambridge
Mitigations Language design Compartmentalisation

7. Project Verona
A new language for safe infrastructure
programming
With David Chisnall, Sylvan Clebsch, Manuel Costa, Sophia
Drossopoulou, Juliana Franco, Mads Torgersen, …

8. The application spectrum
C#
C/C++
Asm
Today
Boot loader/HAL
Core OS components Schedulers/Memory management
Exchange/ ASP.NET
Azure Storage/ Cosmos/ Data lake
Azure functions
Desktop Apps
Device drivers
Systems Programming

9. The space
• Fine grained control
• Resource management
• Latency sensitive
• Close to machine
• No abstraction over memory
• No type safety
Systems Programming

10. The application spectrum
C#
C/C++
Asm
Today
Boot loader/HAL
Core OS components Schedulers/Memory management
Exchange/ ASP.NET
Azure Storage/ Cosmos/ Data lake
Azure functions
Desktop Apps
Device drivers
Infrastructure
Programming

11. The space
• Fine grained control
• Resource management
• Latency sensitive
• Close to machine
• No abstraction over memory
• No type safety
Inherently unsafe
Possible for safe by construction

12. Core ideas
• Give up concurrent mutation, to enable scalable memory management.
Data-race
freedom
• New concurrency model that provides lightweight asynchronous coordination.
Concurrent
Owners
• passing groups of objects
• memory management strategies per region (reference counting, tracing, arenas, …)
• Compartmentalisation for legacy components
Linear Regions

13. Shared
immutable region
Linear mutable
region
Single entry pointRegions are only
accessed by one
computation at a time

14. Pervasive sandboxing
Verona program
C++ runtime library
C library
C / Assembly
library
C++ library
C/C++ library
C++ library
TCB,
needs
careful
auditing
Sandboxed, scope of
vulnerabilities
limited

15. Libraries are special
untrusted regions

16. Project Verona
status
Production quality runtime
Prototype interpreter and type checker
Compiler not started
Open-sourcing to github soon to enable collaborations
Ask me for a demo!

17. CHERI

18. CHERI for
mitigations
Which exploit chains does CHERI break?
What gadgets can exist on CHERI?
Can temporal safety be achieved?
Microsoft Red team (attack) internship analysed security of CHERI
– 12 weeks not long enough to be conclusive
Need a thorough security analysis before it can be adopted as a
mitigation.

19. CHERI for legacy
Lightweight
compartmentalisation
• Contain existing libraries
• Single address space
• How can we build application
that have hundreds of
sandboxed libraries?
Low-cost containers
• Density important for the
cloud
• Can CHERI improve density in
Cloud applications?

20. Conclusions
Microsoft needs security for legacy!
Can we capitalise on CHERI to use existing
assets?
Can we architect software to integrate safe
new code with old unsafe legacy code?
Project Verona for compartmentalisation
research collaborations

21. Backup slides

22. Memory
Safety
Scalability
Global
GC
Malloc/Free

23. Regions open up new possibilities
• Compartmentalisation
• Different regions can be compiled with different trust.
• Distributed and heterogenous hardware
• Moving collections of objects between devices – can be part of the
programming model
• Dynamic update of running code
• Each object accessed by at most one thread, updates can exploit this in the
running system

24. Memory
Safety
Scalability
Concurrent
Mutation
Global
GC
Malloc/Free

25. Memory
Safety
Scalability
Concurrent
Mutation
Global
GC
Malloc/Free
Ownership
Single mutator

26. Memory
Safety
Scalability
Concurrent
Mutation
Global
GC
Malloc/Free
Ownership

27. Memory
Safety
Scalability
Concurrent
Mutation
Global
GC
Malloc/Free
Ownership

28. The Sea of
Objects

29. Region access is single-threaded
C#/C++ Region-based ownership
Only one thread operating
on a region at a time

30. Region ownership is hierarchical
C#/C++ Region-based ownership
Regions have a
single entry point