Digital Security by Design: Security and Legacy at Microsoft - Matthew Parkinson, Microsoft
•
8 likes•1,677 views
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
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Digital Security by Design: Security and Legacy at Microsoft - Matthew Parkinson, Microsoft
Similar to Digital Security by Design: Security and Legacy at Microsoft - Matthew Parkinson, Microsoft (20)
More from KTN
More from KTN (20)
Recently uploaded
Recently uploaded (20)
Digital Security by Design: Security and Legacy at Microsoft - Matthew Parkinson, Microsoft
- 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
- 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
- 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