By Anders Fogh, Senior Principal Engineer at Intel
The software stack has long been a fruitful target for hackers looking to exploit organizations – and this is not likely to change anytime soon. As a matter of fact, according to the Common Vulnerability and Exposures (CVE) list, there were 14,760 known security vulnerabilities logged in 2018 alone (a record year). As the stakes continue to rise in this cat and mouse game, so too has the scrutiny of these systems, resulting in more robust software security development lifecycles, enhanced vendor collaboration, and increased mitigations that help combat malicious activity. If software vulnerabilities have reached adolescence (metaphorically speaking), one could say that hardware vulnerabilities are just entering early childhood. Take for example the nascent CPU exploits like Meltdown and Spectre, which were disclosed in early 2018. Both of these hardware vulnerabilities have had a significant impact on the security industry.
As hardware vendors work to overcome new security challenges and create an ecosystem capable of properly disclosing, tracking and resolving these vulnerabilities, I wanted to share some of the key differences between software and hardware mitigations.
- The Flexibility Issue
In today’s threat landscape, the software is still orders-of-magnitude easier to handle than hardware. One of the most obvious reasons why is the simple fact that software can be updated frequently to deal with security vulnerabilities. For example, if there is a buffer overflow attack in software, once the root cause is identified, new code can quickly be pushed to address the issue. It’s even commonplace for some vendors to release patch updates in less than 48 hours. The agility that’s present in software just simply doesn’t exist in most hardware. And while there is some wiggle room built into hardware firmware – for example, the ability to modify a CPU’s UEFI (commonly referred to as BIOS), or the ability to turn things on and off in hardware for mitigation reasons and product variants (what’s colloquially known as modifying chicken bits) – None of these compare to the ultimate flexibility of a completely software architected solution.
- The Development Cycle
The software development cycle is dramatically different from that of hardware in many ways, and a primary reason is the manufacturing component. In CPU hardware, when you eliminate the ability to fix a problem through firmware or chicken bits, what’s left is a fundamental design change. This results in the need to evaluate the old hardware, identify the problem, formulate the updates, coordinate with ecosystem partners, and push to manufacturing for the new build. The challenges are complex and time-consuming. On the other hand, the software can modify a feature via code changes and pushing an update, hardware usually cannot. This is why with the advent of hardware vulnerabilities, security researchers play a huge role in helping to build the next generation of hardware systems that are not only more secure, but also architected in a way that can be updated or modularized for security mitigations.
- The Stack Problem
Traditionally speaking, software sits on top of the system stack – meaning software depends on other components, and not the other way around. For developers and security professionals in software, this offers ultimate flexibility with other vendors and customers. But, the further down in the stack you go, the more the elements above depend on you to function properly. For example, if an operating system were to change its API significantly, the software running on top of it would likely break. But hardware is usually the lowest element in the stack. For instance, a CPU has to interface with an operating system, which interfaces with an application, and so on. Hardware changes in these complex relational environments are ultra-sensitive. It requires depth in testing that can take substantial resource and time. And, the documentation and specification for usage have to be extremely comprehensive.
- The Product Lifecycle
Very few things last forever. And in the world of hardware, there’s no such thing as a partial replacement. Software, on the other hand, is often continually being updated via code to the next version. With hardware, it’s traditionally out with the old, in with the new. And unfortunately, hardware usually carries significant cost implications, so products like CPUs and hard drives tend to have a long shelf life. This also means that the number of models being supported in the wild is often much higher than with software. This can have a major impact on hardware mitigations and add to the design pressure. In essence, with hardware, you have to live with what you built ten years ago. As a result, today’s hardware vendors are transforming R&D processes to be more inclusive of security teams in hopes of making future products more flexible.
- The Update Challenge
In general, a software update is simple. Push the patch, update the code, fix the problem (at least that’s the basic idea). In the world of hardware mitigations, it can be much more complex. Hardware is not often directly connected to the internet or a network. This means hardware vendors rely on OEMs to set up mechanisms to push or pull updates or coordinate with software partners to push updates to customers. For example, Intel has made microcode updates OS loadable, meaning when mitigation can be fixed via firmware, a microcode patch can be released through operating system partners. But, it’s much more complex than that. It requires an incredibly high level of coordination between the stack layers. For instance, the degree to which a CPU microcode update impacts a cloud provider versus a data center can vary dramatically. It’s not one-size-fits-all mitigation, yet it’s expected to be, which means these partners need time to test the mitigation before they push it to their customers.
Looking Ahead
To help overcome the challenges of hardware vulnerability mitigations, there is a lot of great work happening in this space today. To cite just a few examples, we’re seeing more flexibility being designed into the firmware, for example, changes that give microcode more flexibility to fix potential security problems are being designed into next-generation hardware. Updates are becoming more agile, for example, Intel microcode updates are distributed as part of Microsoft’s patch Tuesday. And big vendors are participating in more open source projects, for example Intel heavily contributes to the Linux Kernel.
The goal is to make hardware ecosystems of tomorrow more secure than today. While there are some early successes we can point to – such as the quick integration of hardware mitigations for the Meltdown vulnerability in Intel’s 8th generation processor family (Coffee Lake) – our community must continue to drive toward the development of more formal methods and standards for disclosing, tracking and sharing hardware mitigations. This will ensure that research and education in hardware mitigations mirror the maturity of the software security industry, and as a complete industry, we more effectively tackle security mitigations.
About the Author
Anders Fogh is a Senior Principal Engineer at Intel. He has been involved in software development and information security for more than two decades and is an expert in reverse engineering. Anders can be reached on Twitter @anders_fogh and through the company website http://www.intel.com.
