Security Week 28: NetSpectre, attack on third-party channels through a network

Again! Just two weeks ago, we talked about Specter’s new attack options using the speculative recording method. The most important news of last week is once again devoted to the Specter family, and now everything is much cooler. Researchers from the Technical University of Graz in Austria have found a way to extract data from a third-party channel remotely, hence the name of the attack.

I would like to say that the NetSpectre attack does not require the execution of any code on the attacked system (unlike, for example, the browser-based attack on JavaScript), but this is not quite so. In the context of NetSpectre, the “code” is routine work with other computers on a network that the attacker does not directly control, but can influence it. The ability to remotely detect the microscopic difference between different processor modes is impressive. As with other Specter studies, the work is (so far) theoretical in nature, and the new attack has an incredibly slow data extraction rate: units of bits per minute. A review of the new attack (in human language) is published here , although it is still better to read the original research .


Prior to the publication of research NetSpectre as an exemplary remote attack on the mechanism of the speculative execution of code usually offered JavaScript code running in the browser. This method, according to the authors of the new work, provided the possibility of a fairly accurate measurement of the delays between the request and the receipt of data. As it happens in principle in Specter attacks (and there are already a lot of them), the difference in response time allows reconstructing the data to which the executed program does not have access.

NetSpectre does not require an attacker to directly execute code on the target system. Instead, the usual data exchange over the network is used, for example, downloading files from the attacked server and sending single network packets. The researchers created an artificial design from a vulnerable server (in one of the examples it was a computer with an Intel Core i5-6200U processor), in the network software of which two gadgets were present. Gadgets mean a certain mechanism that implements certain properties we need, the software part of the vulnerability. The "leak gadget" created the conditions for the speculative inquiry of secret data in a more or less standard for Specter-like attacks by:


The term for the second gadget is a bit confusing. Naturally, the “transfer gadget” is not a vulnerability that directly transfers secrets from the RAM or CPU cache to an attacker, as happens in the simpler Heartbleed attack (four years have passed, you must do the same!). The “transfer gadget” creates conditions when an attacker can analyze the delay in data transfer from which it is possible to reconstruct the necessary information.

Researchers have proposed two third-party data leakage channels for the NetSpectre attack. The first almost completely repeats the mechanism of the original Specter and uses the processor cache. The second does not use the cache at all: instead, the block of calculations for instructions from the AVX2 set is activated. Since these blocks are characterized by high energy consumption, they are switched off in the absence of a load. Upon receipt of instructions from the set, their inclusion occurs with a slight delay, which can also be measured remotely. This method turns out to be several times faster than “traditional” cache manipulations: the data was reconstructed through the cache under the conditions of a gigabit local network at 4 bits per minute, and using AVX2 in a minute it was possible to transfer 8 bytes.

Why so slow? You can understand, for example, by this picture from the study:


The original Specter attack, which runs directly on the attacked system, requires measuring the delays in the processor’s response to instructions of the order of milliseconds. It is also rather slow - data theft is possible at speeds in units of kilobits per second. Anything can affect the delay in the transmission of network packets, so NetSpectre “measures” —that is, in essence, conducts a successful attack — many times in a row in order to get the required bit or byte from averaged values ​​with high confidence.

So, a reasonable attack accuracy is achieved with hundreds of thousands and millions of measurements . In eachof these, you need to carry out a complex operation, which includes, for example, resetting the cache memory by downloading a 590 kilobyte file. By the way, when processing data, machine learning algorithms were not used: they, obviously, will help reduce the number of measurements necessary for accurate data reconstruction. When the attacker and the victim are not in the same local network, such algorithms will be needed, otherwise one byte will be “transmitted” in 160 million measurements (!) Within 8 hours (3 hours using the AVX2 method).

The researchers successfully carried out the attack using computers and laptops on Intel processors, devices on processors with the ARM Cortex A75 core, and also on the Google Cloud Platform (between two virtual machines). I repeat once again, the attack is completely theoretical. To implement it in real conditions, you need to find the appropriate "gadgets" in a particular software version (for example, the Linux kernel) installed on a specific server. It is necessary to provide conditions for interaction with the server, which are not always feasible. In particular, the researchers directly indicate that any means to protect against DDoS attacks will ban an attacker almost instantly - due to the number of requests and the amount of data transferred. Even the processor model inside the line does matter: for the cache used in the Core i5 with three megabytes, it will work

But still impressive! This is more awesome than some kind of “laser” microphones that take vibrations from windows in a room. NetSpectre does not bring additional risks: Intel commented on the work in the vein that Specter’s already known mitigation methods work for network incarnation. I will proceed from the speed of developing new methods of attack - and suppose that the most interesting ways to steal data through an open window is still ahead. No matter how much they cost us all, in the context of a forced drop in productivity and the need for capital expenditures on the part of vendors.

Disclaimer: The opinions expressed in this digest may not always coincide with the official position of Kaspersky Lab. Dear editors generally recommend to treat any opinions with healthy skepticism.