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
Is Threat Intelligence Garbage?
Chris McDaniels, Chief Information Security Officer of Mosaic451,  5/23/2018
New Mexico Man Sentenced on DDoS, Gun Charges
Dark Reading Staff 5/18/2018
What Israel's Elite Defense Force Unit 8200 Can Teach Security about Diversity
Lital Asher-Dotan, Senior Director, Security Research and Content, Cybereason,  5/21/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Shhh!  They're watching... And you have a laptop?  
Current Issue
Flash Poll
[Strategic Security Report] Navigating the Threat Intelligence Maze
[Strategic Security Report] Navigating the Threat Intelligence Maze
Most enterprises are using threat intel services, but many are still figuring out how to use the data they're collecting. In this Dark Reading survey we give you a look at what they're doing today - and where they hope to go.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-3018
PUBLISHED: 2018-05-24
The AXIS webapp in deploy-tomcat/axis in IBM Tivoli Application Dependency Discovery Manager (TADDM) 7.1.2 and 7.2.0 through 7.2.1.4 allows remote attackers to obtain sensitive configuration information via a direct request, as demonstrated by happyaxis.jsp. IBM X-Force ID: 84354.
CVE-2013-3023
PUBLISHED: 2018-05-24
IBM Tivoli Application Dependency Discovery Manager (TADDM) 7.1.2 and 7.2.0 through 7.2.1.4 might allow remote attackers to obtain sensitive information about Tomcat credentials by sniffing the network for a session in which HTTP is used. IBM X-Force ID: 84361.
CVE-2013-3024
PUBLISHED: 2018-05-24
IBM WebSphere Application Server (WAS) 8.5 through 8.5.0.2 on UNIX allows local users to gain privileges by leveraging improper process initialization. IBM X-Force ID: 84362.
CVE-2018-5674
PUBLISHED: 2018-05-24
This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of Foxit Reader before 9.1 and PhantomPDF before 9.1. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw...
CVE-2018-5675
PUBLISHED: 2018-05-24
This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of Foxit Reader before 9.1 and PhantomPDF before 9.1. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw...