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: Hardware Memory Safety: Challenges and Opportunities - Manuel Costa, Microsoft Research Cambridge

100 views

Published on

KTN ran a collaborators' workshop on 26 September 2019 in London to explain more about the Digital Security by Design Challenge announced by the government.

The Digital Security by Design challenge has been recently announced by the Department for Business, Energy & Industrial Strategy (BEIS). This challenge, amounting to £70 million of government funding over 5 years, was delivered by UK Research and Innovation (UKRI) through the Industrial Strategy Challenge Fund (ISCF).

This Collaborators' Workshop provides an opportunity to hear more details of the challenge and forthcoming competitions.

A Scoping Workshop for this challenge was held on 30th May: http://ow.ly/oz6230pHlGl


Find out more about the Defence and Security Interest Group at https://ktn-uk.co.uk/interests/defence-security

Join the Defence and Security Interest Group at https://www.linkedin.com/groups/8584397 or Follow KTN_UK Defence group on Twitter https://twitter.com/KTNUK_Defence

Published in: Design
  • Be the first to comment

  • Be the first to like this

Digital Security by Design: Hardware Memory Safety: Challenges and Opportunities - Manuel Costa, Microsoft Research Cambridge

  1. 1. Hardware Memory Safety Challenges and Opportunities Manuel Costa Microsoft Research Cambridge
  2. 2. Memory safety is the root cause of most vulnerabilities [CELLRANGE] [CELLRANGE] [CELLRANGE] [CELLRANGE] [CELLRANGE] [CELLRANGE] [CELLRANGE] [CELLRANGE] [CELLRANGE] [CELLRANGE] [CELLRANGE] [CELLRANGE] [CELLRANGE] [CELLRANGE] [CELLRANGE] [CELLRANGE] [CELLRANGE] Memory Corruption CVEs-2017 by Microsoft We need solutions to memory safety
  3. 3. Memory safety is the root cause of most vulnerabilities [CELLRANGE] [CELLRANGE] [CELLRANGE] [CELLRANGE] [CELLRANGE] [CELLRANGE] [CELLRANGE] [CELLRANGE] [CELLRANGE] [CELLRANGE] [CELLRANGE] [CELLRANGE] [CELLRANGE] [CELLRANGE] [CELLRANGE] [CELLRANGE] [CELLRANGE] Memory Corruption CVEs-2027 by Microsoft We need solutions to memory safety
  4. 4. Existing deployed mitigations Control Flow Guard (CFG) Enforce control flow integrity on indirect calls Shipped Prevent control-flow hijacking Arbitrary Code Guard (ACG) Prevent dynamic code generation, modification, and execution Code Integrity Guard (CIG) Images must be signed and arbitrary images cannot be loaded Shipped Shipped Prevent arbitrary code generation
  5. 5. Examples of recent progress This bug class accounted for 49 vulnerabilities reported to MSRC in 2017-2018 (~4%) We’ve been adopting span in key code bases (e.g. Hyper-V) and it has already helped eliminate vulnerabilities that were later identified
  6. 6. Towards getting to done with vulnerabilities increasing cost & difficulty getting to done Focus more on making it durably hard for developers to make mistakes while retaining good perf & dev efficiency
  7. 7. Challenges with breaking exploitation techniques Place array base or length at predictable location Modify array base or length discover DLL base address discover DLL base address & stack address Construct ROP payload Corrupt state of security policy Read sensitive content Corrupt function pointer Corrupt return address Corrupt C++ virtual table pointer Execute ROP payload Execute arbitrary native code Morello/CHERI breaks key points in common exploit chains
  8. 8. Bounds checks in software can be expensive get: ldr w0, [x0, w1, sxtw #2] ret get: sxtw x8, w2 cmp x0, x8 b.ls .LBB0_2 ldr w0, [x1, x8, lsl #2] ret .LBB0_2: bl gsl::details::terminate() No bounds checks Span bounds checks Load the bounds Check the bounds Abort int get(gsl::span<int> a, int b) { return a[b]; }
  9. 9. Bounds checks in hardware are cheaper get: ldr w0, [x0, w1, sxtw #2] ret get: ldr w0, [c0, w1, lsl #2] ret No bounds checks Span bounds checks with Morello int get(gsl::span<int> a, int b) { return a[b]; }
  10. 10. Safe languages depend on systems languages for security 0 1,000,000,000 2,000,000,000 3,000,000,000 4,000,000,000 5,000,000,000 6,000,000,000 7,000,000,000 8,000,000,000 9,000,000,000 C C++ Rust JavaScript Java C# Data from OpenHub.NET Safe Languages Systems Languages Linesofpubliccode
  11. 11. Safe languages need a secure migration path SANDBOXED LEGACY LIBRARIES HARDWARE MEMORY SAFETY FOR CLOSELY COUPLED C++ CODE ACCELERATION FOR COMMON SAFETY CHECKS
  12. 12. Securing the cloud with new hardware
  13. 13. 54 REGIONS WORLDWIDE 100K+ MILES OF FIBER AND SUBSEA CABLE 130+EDGE SITES 200+ExpressRoute Partners
  14. 14. Azure Confidential Computing Code Data Goal: Provide the highest levels of privacy and security for Azure workloads New architecture based on hardware-based Trusted Execution Environments (TEEs) New instructions to set aside private regions (“protected containers”) of code and data Data is only ever in the clear within the hardware-protected containers Minimizes attack surface
  15. 15. SQL Always Encrypted Secure computations inside SQL Enclave Rich queries In-place encryption Protects sensitive data in use while preserving rich queries and providing in- place encryption ciphertext C: Enhanced Client Driver TEE plaintext
  16. 16. User User User User Current State key-value store Bring your own code replication between trusted execution environments Primary Member User User User Member User consortium Backup Verifiable Ledger Verifiable Ledger authenticated encryption & signatures untrusted storage secure channel (TLS) untrusted network untrusted hosts security spec distributed implementation clients secure service Member Member Governance consortium Confidential Consortium Framework
  17. 17. Research and development opportunities Performance analysis and optimizations Language and hardware co-design Making existing mitigations more efficient Compartmentalizing applications Reasoning about guarantees of compartmentalized applications Efficient temporal safety Supporting legacy codebases
  18. 18. Summary Mitigating/eliminating memory safety exploits is crucial Microsoft is eager to adopt hardware innovations Many interesting avenues for research and development Looking forward to partnering on this journey together

×