Security Weekly 51: NetSpectre, Attack On Third-Party Channels Over A Network
Again! Just two weeks ago, we talked about new variants of the Specter attack, using the method of speculative recording.
The most important news of last week is again devoted to the Specter family, and now everything is much steeper. 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 attack of NetSpectre does not require execution of any code on the attacked system (in contrast, for example, from browser attacks on JavaScript), but this is not entirely true. In the context of NetSpectre, the “code” is the routine work with other computers over the network, which the attacker does not directly control, but can influence it. Impressive is the ability to remotely detect a microscopic difference between different operating modes of the processor. As with other Specter studies, the work is (yet) theoretical in nature, and the new attack is characterized by an incredibly slow data extraction rate: bits per minute. The review of the new attack (human language) is published here, although it is still better to read the original study.
Prior to the publication of the NetSpectre research, as an indicative remote attack on the mechanism of speculative code execution, JavaScript was usually offered 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 query and the receipt of data. As it happens in principle in attacks like Specter (and there are already a lot of them), the difference in response time allows you to reconstruct the data, which the program does not have access to.
NetSpectre does not require the attacker to directly execute code on the target system. Instead, you use regular data exchange over the network, for example, downloading files from the attacked server and transferring single network packets. The researchers created an artificial design from a vulnerable server (in one example it was a computer with an Intel Core i5-6200U processor), in the network software of which there were two gadgets. Gadgets mean a certain mechanism that implements certain properties we need, the soft part of the vulnerability. “Leakage Gadget” created conditions for the speculative query of secret data more or less standard for Specter-like attacks by:
- The term for the second gadget is a little confusing. Naturally, the “transfer gadget” is not a vulnerability that directly transfers the secrets from the RAM or the CPU cache to the attacker, as it happens in a more simple Heartbleed attack (four years have already passed, right!). “Transmission Gadget” creates conditions when an attacker can analyze the delay in the transfer of data, from which you can reconstruct the necessary information.
Researchers suggested 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’s cache. The second one does not use the cache at all: instead, the calculation unit of instructions from the AVX2 set is used. Since these units are characterized by high energy consumption, they are disabled when there is no load. When the instructions are received from the kit, they are switched on with a slight delay, which can also be measured remotely. This method turns out to be several times faster than the “traditional” cache manipulation: data reconstruction through the cache occurred in a gigabit LAN environment at a rate of 4 bits per minute, and with AVX2 it was possible to transfer 8 bytes per minute.
Why so slow? You can understand, for example, from this picture from the study:
The original Specter attack performed directly on the system being attacked, requires measurement of delays in the processor’s response to instructions of the order of milliseconds. It is also quite slow – “data theft” is possible at a speed of one kilobit per second. The delay in the transmission of network packets can be affected by anything, so NetSpectre “measures” – that is, in effect, conduct a successful attack – many times in a row, to get the required bit or byte from the averaged values with high reliability.
- So, the reasonable accuracy of attack is achieved with hundreds of thousands and millions of measurements. Each of them requires a complex operation, which includes, for example, resetting the cache memory by downloading a file of 590 kilobytes. By the way, in the processing of 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 victim are not in the same local network, such algorithms will be needed, otherwise, one byte will be “transmitted” for 160 million measurements (!) Within 8 hours (3 hours using the AVX2 method).
The researchers successfully conducted the attack, using computers and laptops on Intel processors, devices on processors with ARM Cortex A75 core, and also on the platform Google Cloud Platform (between two virtual machines). Once again, the attack is completely theoretical. To implement it in real conditions, you need to find the appropriate “gadgets” in a specific software version (for example, the Linux kernel) installed on a particular 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 bite the attacker almost instantly – due to the number of requests and the amount of data transferred. Even the processor model inside the line has a value: for the Core i5 with three megabytes used in the work, the cache will work, and for some other (with a different cache size), perhaps not.
But still impressive! This is more abrupt than any “laser” microphones, which remove vibrations from windows in the room. Additional risks NetSpectre does not bring: Intel commented on the work in the vein that already known methods of mitigation Specter also work for a network incarnation. I will proceed from the speed of developing new methods of attack – and I will assume that the most interesting ways of stealing data through an open window still lie ahead. How would they not cost us all a penny – in the context of a forced fall in productivity and the need for capital costs from vendors?
