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 better. 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 system being attacked (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 the different modes of operation of the processor is impressive. As in the case of other Specter studies, the work is (so far) theoretical, 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) has been published here , although it is still better to read the original research .


Prior to the publication of the NetSpectre study, a typical example of a remote attack on a speculative code execution engine was usually JavaScript code that was executed 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 (there are already a lot of them), the difference in response time allows you to reconstruct data that the program you are running does not have access to.

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 example, this 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, wow!). The “transfer gadget” creates conditions when an attacker can analyze the delay in data transfer from which you can 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 one does not use the cache at all: instead, the block of calculations of 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, on 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 obtain the required bit or byte from the averaged values ​​with high confidence.

So, reasonable accuracy of attack is achieved with hundreds of thousands and millions of measurements . In each of them you need to carry out a complex operation, which includes, for example, resetting the cache memory by loading 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, as well as 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 of cache, it will work for some other (with a different cache size).

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 incarnations. 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.