The Spectre of an Advertising Meltdown: What You Need to Know

Nicholas Weaver
Thursday, January 4, 2018, 12:48 PM

The information security world is focused on two new security vulnerabilities, “Spectre” and “Meltdown”, that represent vulnerabilities embedded in computer hardware. Lawfare readers should respond in two ways: keep their operating systems up to date and, critically, install an ad-blocker for your web browser.

Published by The Lawfare Institute
in Cooperation With

The information security world is focused on two new security vulnerabilities, “Spectre” and “Meltdown”, that represent vulnerabilities embedded in computer hardware. Lawfare readers should respond in two ways: keep their operating systems up to date and, critically, install an ad-blocker for your web browser. (Here are guides on how to do so in Chrome and Firefox.) In fact, a proper response to Spectre should involve ad-blocking on all government computers. Other than that, don’t worry.

Readers who just wanted to know what to do can stop reading. But for those curious about some of the technical background on these vulnerabilities and why ad-blocking is an essential security measure for a modern computer, read on.

Modern Computers: Caches, Parallelism, and Isolation

Modern computers are incredibly complicated but almost all the performance comes from attempting to exploit two concepts: caches and parallelism. And modern computer security often rests on a principle of isolation, blocking the ability of one program to learn or affect what else is happening on the computer. Spectre and Meltdown exploit breaches of isolation due to the interaction of caches and some parallelism features.

A cache is just something holding the previous result, under the assumption that “what you do in the future is often the same as what you do in the past.” So you have instruction caches that hold previously executed instructions, since a program is likely to execute the same instruction again, and data caches that hold previously accessed memory. But there are also more obscure caches, such as the “Branch Target Buffer” (BTB), which records where previous instructions jumped to in an attempt to predict that branch in the future, or the “Translation Lookaside Buffer” (TLB), which remembers mappings between virtual addresses and the actual locations in the computer’s main memory. If a relevant result is in the cache, an operation happens quickly, otherwise that operation is slow.

Parallelism just means doing multiple things at the same time. This can be at a low level, such as observing that in the following miniature program, “X = A + B; Y = C * D,” it is possible to compute X and Y at the same time. Or it can be at the scale of a Google data center where tens of thousands of computers are all working on different parts of the problem.

One particular method for increasing performance is speculative and out of order execution. So if the computer sees a program like “if (X) then (Y = A + B)”, even if it hasn’t discovered what X is, it can still try to compute Y = A + B. But the computer will only actually write the value Y if it discovers X is true and will only attempt to compute Y if it thinks the branch will be taken based on the branch predictor and its BTB. Of course how long this process takes depends on the state of all the caches as well as the final result of determining the value of X.

While processor designers attempt to squeeze every last bit of performance out of a combination of caches and parallelism, security engineers rely on isolation. If two programs are running on a computer, it is critical that one program is not able to deduce information about the other. There are several important barriers to that effect.

A user program should not be able to read information contained in operating-system memory while a JavaScript program should not be able to read out information from other web pages or the web browser. If this isolation fails, we lose our security guarantees, as a hostile program can read passwords out of memory or other sensitive information such as authentication cookies or cryptographic keys. Both Spectre and Meltdown exploit the interactions between speculative execution and various caches to read information across security barriers by observing how long various operations take.

Meltdown, which exploits a weakness in Intel’s TLB to allow a normal program to read the operating system’s private memory, is easy to exploit, but there are already robust patches available. Unfortunately, these patches substantially degrade performance as they require clearing the TLB whenever the operating system returns. Since the TLB is a particularly critical cache, losing the cache state can be particularly hard on performance. Some computer workloads, such as those that rely on a lot of operating system calls, may see a worst-case 20% reduction in performance.

Spectre, on the other hand, exploits a more general flaw in the interaction between the branch predictor and speculative execution to read information across an isolation barrier. It takes considerably subtler code to exploit but, unlike Meltdown, can specifically enable a JavaScript program to read secrets from the web browser. And subtlety in exploitation is not a substantial protection, as it only takes one clever hacker to create some code every other miscreant can use.

Spectre-type vulnerabilities can affect all modern out-of-order CPUs—whether designed by Intel, AMD, or ARM—and although there is effort by browser vendors to mitigate the threat of Spectre-type attacks in JavaScript, these patches are not considered robust even if they do block the initial Spectre-JavaScript proof of concept. So Spectre attacks remain a potential threat even on a fully patched system, even though there is no known attack currently working.

Modern Web Advertisement: Auction and Syndication

The danger from Spectre attacks is substantially magnified by how modern advertising works on the internet. The web browser maintains a key set of isolation barriers, called the same origin policy, that are designed to prevent JavaScript running in one website from reading key information (such as authentication cookies) belonging to a different website. If this isolation barrier ever fails, malicious JavaScript can steal secrets at will.

And it is relatively easy for an attacker to cause a victim’s browser to run the attacker’s JavaScript. Often when you visit a web page with advertisements, an online auction decides who gets to provide you with a JavaScript-laden ad. The process, although fast, can include multiple auctions as an intermediary bids for your pageview and then immediately auctions it off again in a different marketplace. You may be bought and sold several times in a few hundred milliseconds. And it only takes bids from one bad actor somewhere along the chain to have your browser running the attacker’s advertisement.

This naturally results in “malvertising,” malicious advertisements where the JavaScript attempts to do something bad. This could be as innocuous as a fraudulent pop-up claiming you can get a “free Nexus for winning the Google Lottery,” as annoying as a cryptocurrency miner that slows down your browser while it runs, or as dangerous as a browser exploit attempting to either steal secrets or exploit your computer. Spectre-type attacks are particularly well-suited for distribution through malvertising, since there is no current robust defense widely deployed against them.

Malvertising has been a problem for a decade, and the web advertisement ecology has completely failed to make headway. Thus, I have long recommend ad-blocking not to remove annoyances but simply to eliminate a huge security problem. The rise of Spectre-class attacks in JavaScript is just merely one more reason to eliminate advertisements from the browser both on an individual and network-wide level.

So although both vulnerabilities are fascinating and yet another great show of the security industry dancing madly on the lip of a volcano, most Lawfare readers only need to know two things: keep your systems patched and install an ad-blocker. And there is one policy prescription: deploy government-wide ad-blocking.

Nicholas Weaver is a senior staff researcher focusing on computer security at the International Computer Science Institute in Berkeley, California, and Chief Mad Scientist/CEO/Janitor of Skerry Technologies, a developer of low cost autonomous drones. All opinions are his own.

Subscribe to Lawfare