Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Digital Security by Design: Security and Legacy at Microsoft - Matthew Parkinson, Microsoft

4,687 views

Published on

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

Published in: Design
  • Be the first to comment

Digital Security by Design: Security and Legacy at Microsoft - Matthew Parkinson, Microsoft

  1. 1. Security and Legacy at Microsoft MATTHEW PARKINSON PRINCIPAL RESEARCHER, CONFIDENTIAL COMPUTING, MICROSOFT RESEARCH
  2. 2. Motivation Microsoft cares about security Microsoft cares about legacy
  3. 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. 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. 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. 6. Our research in Cambridge Mitigations Language design Compartmentalisation
  7. 7. Project Verona A new language for safe infrastructure programming With David Chisnall, Sylvan Clebsch, Manuel Costa, Sophia Drossopoulou, Juliana Franco, Mads Torgersen, …
  8. 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. 9. The space • Fine grained control • Resource management • Latency sensitive • Close to machine • No abstraction over memory • No type safety Systems Programming
  10. 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. 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. 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. 13. Shared immutable region Linear mutable region Single entry pointRegions are only accessed by one computation at a time
  14. 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. 15. Libraries are special untrusted regions
  16. 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. 17. CHERI
  18. 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. 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. 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. 21. Backup slides
  22. 22. Memory Safety Scalability Global GC Malloc/Free
  23. 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. 24. Memory Safety Scalability Concurrent Mutation Global GC Malloc/Free
  25. 25. Memory Safety Scalability Concurrent Mutation Global GC Malloc/Free Ownership Single mutator
  26. 26. Memory Safety Scalability Concurrent Mutation Global GC Malloc/Free Ownership
  27. 27. Memory Safety Scalability Concurrent Mutation Global GC Malloc/Free Ownership
  28. 28. The Sea of Objects
  29. 29. Region access is single-threaded C#/C++ Region-based ownership Only one thread operating on a region at a time
  30. 30. Region ownership is hierarchical C#/C++ Region-based ownership Regions have a single entry point

×