Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

1/26/2018
10:30 AM
Bill Horne
Bill Horne
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
100%
0%

Hardware Security: Why Fixing Meltdown & Spectre Is So Tough

Hardware-based security is very difficult to break but, once broken, catastrophically difficult to fix. Software-based security is easier to break but also much easier to fix. Now what?

The security world has been rocked by Meltdown and Spectre, two critical hardware security exploits affecting every device from smartphones to desktops to cloud servers. One lesson to learn here is that hardware security alone is not a panacea.

Memory isolation is arguably the most important security feature in modern computer architecture. For example, a malware-infested game should not be able to get access to your banking app's login and password. These exploits demonstrate that isolation is now fundamentally broken.

Meltdown and Spectre did not come out of thin air. They are based on a long line of research on micro-architectural attacks that have been going on for over 15 years. There have been dozens of researchers doing work in this space that have led to this result. But, unless you were a part of that community, or paying very close attention, you probably had no idea that something like this was even possible.

How do these attacks work? Modern CPUs are designed to run faster using a technique called speculative execution. In this technique, the CPU looks a few steps ahead to predict what memory it might need to access and grabs that memory ahead of time, so that it is ready to go when a downstream instruction finally executes. Meltdown and Spectre effectively allow one program to read the contents of another program's memory.

The problem is that the only direct fix for these vulnerabilities is replacing the CPU. Not only would that be exorbitantly expensive, but almost every modern CPU has this flaw, so it's not even a viable option. We may have to wait for completely redesigned CPU architectures before we have systems fundamentally secure against Meltdown and Spectre.

The good news is that there is a workaround to patch the operating system to compensate for this hardware vulnerability, but don't breathe a sigh of relief quite yet. First, it's been reported that these workarounds can result in as much as a 30% impact on performance depending on the program. Second, this affects pretty much every computer and many smartphones and tablets out there, so companies are scrambling to understand their risk exposure, which of their systems are most vulnerable, and how to feasibly deploy patches in any reasonable amount of time.

The Case for Software Security
Most of us take for granted that the safest design principle is to put the most important security functionality under the control of hardware. This includes relying on the OS kernel to be isolated from user programs, relying on hardware roots of trust to bootstrap the security of your system, or pushing cryptographic keys into hardware, where they are hidden from normal programs.

What Meltdown and Spectre have shown us is that hardware-based security is no panacea. Hardware is vulnerable. It can fail. And when it does, the results are ugly and painful.

But then, you might ask, what is the option? Do everything in software? Isn't software fundamentally easy to break? The answer is that everything is relative.

While attacking software does not require as much effort, it is certainly not an easy task either. It's hard enough for a hacker to understand well-documented and designed software, much less software with sophisticated anti-reverse engineering and tamper resistance shields. It can still take thousands of hours to find exploitable software vulnerabilities in such programs, even by the most talented hackers.

Hardware-based security and software-based security sit on two ends of a spectrum. On one end, hardware-based security, is very difficult to break, but once broken, it is catastrophically difficult to fix. On the other end, software-based security, is easier to break, but also much easier to fix.

Not a Binary Choice
This makes for an interesting choice. Is it better to deal with software patches on a regular basis, or put all your chips on hardware and hope there won't be an expensive catastrophic incident down the road? In the case of Meltdown/Spectre, the solution was to roll out a software fix to a hardware failure. In some sense, we are lucky that that option was available.

The choice need not be binary. From a risk management perspective, software security can be an effective hedge against hardware security failures to cushion disasters like Meltdown and Spectre. This is just another way of applying the age-old security maxim of defense in depth.

Consider the issue of protecting cryptographic keys. The hardware solution is to put keys in secure elements, Trusted Platform Modules or Trusted Execution Environments. We've already seen that this kind of hardware can be hacked. An alternative software solution is white-box cryptography, which protects sensitive cryptographic keys by mathematically embedding them within the implementations. Even if a hacker gets to access the code during execution, security properties of white-box cryptography ensure that the keys will still be hidden from the hacker. While it is possible to attack these techniques, it is difficult to achieve. Attackers have had to resort to sophisticated side-channel attacks to be successful. But the security industry has responded with successful countermeasures to defeat these attacks.  

The last thing we want in the security world is to come across a devastating bug and only have partial solutions with potentially substantial performance costs. We need to stop thinking about hardware security as completely impenetrable. Decision makers should seriously consider using software security mechanisms to hedge against catastrophic hardware failures.

Related Content:

Bill Horne leads Intertrust's Secure Systems group. He has authored over 50 peer-reviewed publications in the areas of security and machine learning, and holds 33 granted patents and 44 patents pending. Horne holds a B.S. in electrical engineering from the University of ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Aviation Faces Increasing Cybersecurity Scrutiny
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/22/2019
Microsoft Tops Phishers' Favorite Brands as Facebook Spikes
Kelly Sheridan, Staff Editor, Dark Reading,  8/22/2019
MoviePass Leaves Credit Card Numbers, Personal Data Exposed Online
Kelly Sheridan, Staff Editor, Dark Reading,  8/21/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2016-6154
PUBLISHED: 2019-08-23
The authentication applet in Watchguard Fireware 11.11 Operating System has reflected XSS (this can also cause an open redirect).
CVE-2019-5594
PUBLISHED: 2019-08-23
An Improper Neutralization of Input During Web Page Generation ("Cross-site Scripting") in Fortinet FortiNAC 8.3.0 to 8.3.6 and 8.5.0 admin webUI may allow an unauthenticated attacker to perform a reflected XSS attack via the search field in the webUI.
CVE-2019-6695
PUBLISHED: 2019-08-23
Lack of root file system integrity checking in Fortinet FortiManager VM application images of all versions below 6.2.1 may allow an attacker to implant third-party programs by recreating the image through specific methods.
CVE-2019-12400
PUBLISHED: 2019-08-23
In version 2.0.3 Apache Santuario XML Security for Java, a caching mechanism was introduced to speed up creating new XML documents using a static pool of DocumentBuilders. However, if some untrusted code can register a malicious implementation with the thread context class loader first, then this im...
CVE-2019-15092
PUBLISHED: 2019-08-23
The webtoffee "WordPress Users & WooCommerce Customers Import Export" plugin 1.3.0 for WordPress allows CSV injection in the user_url, display_name, first_name, and last_name columns in an exported CSV file created by the WF_CustomerImpExpCsv_Exporter class.