Written by Developing secure software and systems is hard. Even if the most experienced engineers use the best tools and follow best practices, bugs and vulnerabilities can slip through. Add to that the amount of legacy or 3rd-party code in use today, developer turnover and the use of outsourcing, and we can see that it is very difficult to eliminate all vulnerabilities from within a solution. This is why security by design and defence in depth are important principles. By designing-in security right from the start, and having multiple independent and overlapping methods of protection, the impacts of vulnerabilities can be reduced.
The development language itself can have a significant impact on the types of vulnerabilities a solution can potentially suffer from. For example, memory safety issues are believed to account for over 70% of software vulnerabilities. Some languages such as Java, C#, and Rust are designed to be memory safe. However, the checks and protections these languages introduce may have a performance cost, and the availability of these languages does nothing to address the huge amounts of legacy code written in languages vulnerable to memory safety issues, such as C and C++.
C and C++ are very common languages, typically used for software with high performance requirements, or for applications or libraries which must be compiled for multiple platforms. They provide low-level access to memory, which can be particularly useful for operating systems, embedded devices and for cross-platform applications such as browsers. However, whilst low-level memory access and the availability of pointers can be powerful, it can be easy to make a trivial mistake which can introduce a dangerous memory safety vulnerability.
Digital Security by Design (https://www.dsbd.tech/) is an initiative backed by over 30 partners across industry, academia, and the UK government which aims to address these memory safety issues through enhancements to the processors used within digital devices. The University of Cambridge, part of Digital Security by Design, has been undertaking a research project called Capability Hardware Enhanced RISC Instructions (CHERI https://www.cheri-cpu.org/) which looks to enhance conventional processor architectures with new features to provide software compartmentalisation and fine-grained memory protection.
One benefit of a hardware-centric approach is that, when CHERI-enabled hardware is available for end-users, developers can immediately make use of the new memory protection features by just recompiling their existing software, libraries and legacy code using CHERI capability aware compilers and toolchains. Digital Security by Design reported that in one example, 6 million lines of C/C++ code were recompiled for memory safety with only 0.026% of lines requiring modification. They also say retrospective studies estimate that 66% of memory-safety vulnerabilities were mitigated by just recompiling and running on a CHERI-enabled processor. The overhead of these protections was understood to be generally modest, at around 0% – 5%, although for some pointer-dense workloads this was higher. This may provide a great opportunity for eliminating most memory safety issues without requiring significant developer effort and with minimal performance impact.
For developers who can spend greater effort to improve the security of their software, the enhanced hardware and compilers introduce support for scalable software compartmentalisation. This can be used to separate off sensitive or risky data processing, preventing vulnerabilities or malicious data in one compartment affecting other compartments. One potential use case given was that of a browser which displays images where the goal would be to minimise the risk of processing a malicious image which attempts to use a vulnerability in a JPEG processing library.
One traditional approach to minimise this risk might be to handle each tab of the browser as a separate process, with all the overheads of managing and communicating with separate processes. This would only prevent attacks from escaping out of that tab’s context, it would not do anything to prevent attacks which act on data within the tab itself. However, what CHERI introduces is a scalable way of creating compartments within the same process. This means far more compartments can be created, for example there could be a separate compartment for each image being displayed within a tab. It also allows faster exchange of data between compartments. However, unlike the memory protection feature, software compartments must be carefully designed and will require existing code to be refactored.
Whilst CHERI is a conceptual architecture, Arm took it and created a prototype architecture by merging it with one of their existing processors. The result was Morello (https://www.arm.com/morello). Initially Arm’s Morello prototype was in the form of a FVP (Fixed Virtual Platform), a software-based model that can be used in advance of hardware availability for early research and development. Whilst software models can be good alternatives when hardware is not available, their performance is unlikely to come close to that of real hardware. This was proven during Chyp’s recent trial of running Android on the Morello FVP which took 45 minutes to begin to display the Home screen. This delay was consistent with Arm’s documentation which warns “it can take between 45 minutes to 2 hours until the Home screen is displayed”.
However, what is particularly exciting is Arm’s recent announcement that they have created a real Morello processor with demonstration board, and that organisations can request loans of the hardware via Digital Security by Design. Having actual hardware available promises to greatly improve the performance and experience of trying out Morello and should accelerate the work being done by organisations in porting existing toolchains, software, and operating systems to it. It is likely that it’ll take many years before CHERI-enabled hardware is in the hands of consumers – but if these early steps are anything to go by, it’s possible that it may be the beginning of the end of at least some memory safety issues.
If you are interested in securing your software and services – Consult Hyperion can help you. Hyperlab, Consult Hyperion’s software research and development team, has experience in developing secure solutions across a range of platforms including smartcards, mobile, desktop and cloud, and can help you design and develop your next project. However, if you already have a solution, or you are developing it in house, our security testing practice is available to perform security code reviews and penetration testing of client applications and services.
