Meltdown & Spectre: Computing's 'Unsafe at Any Speed' Problem

Ralph Nader's book shook up the automotive world over 50 years ago. It's time to take a similar look at computer security.

Back in 1965, a young Ralph Nader wrote an evisceration of the US auto industry. This book, Unsafe at Any Speed, attacked the industry for lagging behind best practices with respect to safety — essentially, carmakers were putting the public at risk by their reluctance to invest in safety features. It's hard to believe that over 50 years have passed since then, but at the opening of 2018, and as we deal with serious security and safety issues in the computer world, I've been reflecting on the situation in which we found ourselves half a century ago.

What's triggered this reflection is the rotten start of this year, with the revelation of Spectre and Meltdown, two serious vulnerabilities that between them impact most modern computers. The newspapers and Web have been full of descriptions, and yes, these bugs are as unpleasant as they sound. Unlike most of the things we read about, these represent problems in the actual hardware, so there's no simple software patch that makes everything better. These are not problems that involve a programmer forgetting to check the size of an array; these are problems in the very "brain" of the computer, the CPU.

As chief scientist for a large security company, I'm pretty immune to hype and spin: I deal in realities. As such, I recently gave a company-wide tutorial on these two vulnerabilities (and, really, they involve a class of vulnerabilities rather than discrete things). There's nothing like having to teach how something works to test that you really understand it. In the case of these bugs, I understand them all too well: these are nasty little side-channel attacks that allow the slow leak of data to an attacker.

Let me be technical for a moment. These problems exist and are exploitable because of a few features of the chip: the translation lookaside buffer and memory caching in general (used to make memory access much quicker), speculative and out-of-order execution (used to make the CPU execute a set of instructions more quickly), and, in the case of one version of Spectre, JIT, or just-in-time compilation (used to make interpreted code run more quickly). When I put it like this, do you see a pattern? I do. These are all related to steps we've taken to speed up computing. I get it — people buy CPUs because this year's model is a shade faster than the one they have. Speed good. Lag bad. Features, especially speed, sell.

Computers have moved from an adjacent spot in our lives (I remember my first computer, on which I mostly played Elite, a space trading game) and have become machines that literally are responsible for helping to keep us alive. My cellphone is with me at all times, a computer applies the brakes in my car, my thermostat happily interacts with servers on the Internet to let me know what the weather outside is, and the lights literally stay on because of modern computation. And it's not just me — the entire modern world is based upon secure, safe, reliable computing. There is not one aspect of our lives, from birth to death, that doesn't rely on the magic of computation.

These new vulnerabilities should remind us that the foundation that technologically enables our society is cracked. We have focused on performance, on glitz… more pixels, a couple more gigahertz, animated emojis. The list is endless. But what we haven't done, outside of a woefully small group of people who make security their life's work, is put the safety of that complex, beautiful system ahead of its glitter. I'm picking my words with care — security sounds abstract and cold, but we all "get" what it means to make something safe and what the consequence of something being unsafe can be.

I am in awe at the advances we have made in computation. During my career, I've gone from hand-coding a machine that ran at 3.25MHz and had a whopping 1KB (!) of memory. By way of contrast 30-something years later, my home laptop works away almost 1,000 times faster per core (and it has several of them) and with seven orders of magnitude more memory available. I can deploy cloud services with a wave of my hand, commanding more computation than I ever dreamed. What we have done is amazing. We should look at those accomplishments with pride. We should also look at the lack of attention we have put into security, at the design stage, with dread: without this infrastructure being secure, it means nothing.

My wish, though made with little hope, is that Spectre and Meltdown will be a wake-up call for all of us. For too long, security has been placed second or worse to features and performance. This must change if we are to really realize the benefits that computation can bring to mankind. I don't blame the vendors here, but the entire ecosystem. Security and safety typically haven't been drivers for purchases in IT, and companies can't be blamed for making products that sell. Somehow, this must change.

Ralph Nader's Unsafe at any Speed shook up the automotive world over 50 years ago. Perhaps it's time to apply those same concepts to computation. I don't want to be unsafe at any speed. No matter how fast my computer, if I can't trust it, it's less than worthless — it's downright dangerous.

Dr. Richard Ford is the chief scientist for Forcepoint, overseeing technical direction and innovation throughout the business. He brings over 25 years' experience in computer security, with knowledge in both offensive and defensive technology solutions. During his career, ... View Full Bio

Well, yes. I think we MIGHT be at an inflection point. It's up to us to take it. I do agree that there is significant risk that this is not enough of a jolt for us to really change though. We'll shrug it off until the next time. That's why it's so important for professioanls (like you!) to step up and really try and make our voices heard. I'm there with you - need to change the game!

Trust Dr. Ford to find a cool historical analogy for the current crisis in computing. While I agree wholeheartedly with the sentiments of the article, I think the current state of digital technology may be even more dire than the state of the US automobile industry in the last century.

While Nader very admirably sought to reduce death and injury from poor automobile design choices, the bigger danger, over time, has been our increased reliance upon those automobiles and the fossil fuels they burn. The unchecked ascendency of the automobile turned out to be really bad for the health of humans and the planet on which they live.

Right now, the processes by which we are creating and deploying hardware and software are simply not a sound basis for a headlong rush into a world of AIs and self-driving cars, blockchained-everything and algorithmic data feeds. IMHO, digital technology needs to take a time out and get its act together, before the unforeseen consequences of its flimsy foundations give way and plunge us into disaster.

@RFord: Don't even get me started on lag when it comes to online services these days. With ads, widgets, and all other manner of frills and nonsense, there are websites that load like a frame-heavy Geocities site 20 years ago. (And even with good blocking and filtering, the blocking and filtering takes time -- sometimes, depending upon what it is, more time than if you just let the greyware tracking widget load properly.)

I read a very interesting article (the link of which I will look up when on a different machine) that compared the latency of these older machines and found, quite surprisingly, that CPU speed is no predictor of UI lag. And with that, I'll now start up my old DOS machine and try and play NIBBLES, which is *unplayably* fast now.

Yes, I agree. Part of the problem though is the *buyer* doesn't treat security as a feature - if I offered a more secure machine with a 10% performance penalty, I think I'd get hurt when compared to that less secure machine that's full speed! One of the challenges in the ecosystem is that vendors will continue to make the most competitive product they can, and until that's pushed toward more security by dollars spent, it'll (arguably rightly (!!!)) sit on the back burner.

@RFord: One of the fundamental problems underlying this is that we don't treat security as a feature -- the way the automakers have evolved to the point that they now treat safety as a feature (or, at least, attempt to).

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.

Published: 2017-05-09NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

Published: 2017-05-08unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

Published: 2017-05-08Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

Published: 2017-05-08Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.