New NetSpectre Attack Does Not Require Victim to Download or Run Malicious Code

A new Spectre-class CPU attack has received attention from academic scientists as they recently released a research paper titled “NetSpectre: Read Arbitrary Memory over Network”, which goes into in-depth details on how this class of CPU attack works.

What makes the new Spectre CPU attack a bit scary is that it does not require the attacker to fool their victim into downloading and running malicious scripts on their machine, or even accessing a website that runs malicious JavaScript in the user’s browser.

NetSpectre will simply bombard a machine’s network ports until it finds a way in to achieve its goals.

“Spectre attacks induce a victim to speculatively perform operations that would not occur during strictly serialized in-order processing of the program’s instructions, and which leak a victim’s confidential information via a covert channel to an attacker”

NetSpectre does not come without its own flaws, however. It has an incredibly slow exfiltration speed, around 15 bits per hour for attacks to be carried out via a network connection, and targeting data stored in the CPU’s cache.

In the research paper, the academics were able to achieve up to 60 bits/hour with a special variation of NetSpectre that targeted data processed via the CPU’s AVX2 module, which is specific to Intel CPUs.

In either case, NetSpectre is currently considered too slow to be valuable for attackers, which means NetSpectre is only a theoretical threat, not something that companies should be ducking for cover from just yet. However, as the technology advances, the exfiltration speeds will undoubtedly increase and then we have a whole new class of viable and incredibly easy to perform CPU attacks to worry about.

The new NetSpectre attack is related to the Spectre V1 vulnerability (CVE-2017-5753) that Google researchers revealed earlier this year (2018). This means that all CPUs which could be affected by Spectre V1 are also believed to be NetSpectre, if it is deployed with proper OS and CPU firmware.

There are currently two attack variants for NetSpectre: Extracting data from the target system, and remotely breaking ASLR (Address Space Layout Randomisation) on the target system.

The chain of events for the first kind of attack goes like this:

1. Mistrain the branch predictor.
2. Reset the state of the microarchitectural element.
3. Leak a bit to the microarchitectural element.
4. Expose state of the microarchitectural element to the network.

• In step 1, the attacker mistrains the branch predictor of the victim to run a Spectre attack. To mistrain the branch predictor, the attacker leverages the leak gadget with valid indices. The valid indices ensure that the branch predictor learns to always take the branch, i.e., the branch predictor speculates that the condition is true. Note that this step only relies on the leak gadget. There is no feedback to the attacker, and thus the microarchitectural state does not have to be reset or transmitted.
• In step 2, the attacker has to reset the microarchitectural state to enable the encoding of leaked bits using a microarchitectural element. This step highly depends on the used microarchitectural element, e.g., when leveraging the cache, the attacker downloads a large file from the victim; if AVX2 is used, the attacker simply waits for more than 1 millisecond. After this step, all requirements are satisfied to leak a bit from the victim.
• In step 3, the attacker exploits the Spectre vulnerability to leak a single bit from the victim. As the branch predictor is mistrained in step 1, providing an out-of-bounds index to the leak gadget will run the in-bounds path and modify the microarchitectural element, i.e., the bit is encoded in the microarchitectural element.
• In step 4, the attacker has to transmit the encoded information via the network. This step corresponds to the second phase of the original Spectre attack. The attacker sends a network packet which is handled by the transmit gadget and measures the time from sending the packet until the response arrives.

Attack Method #2: Remotely Breaking ASLR

1. Mistrain the branch predictor.
2. Access an out-of-bounds index to cache a (known) memory location.
3. Measure the execution time of a function via the network to deduce whether the out-of-bounds access cached a part of it.

Spectre Countermeasures

Intel and AMD recommend using the lfence instruction as a speculation barrier. This instruction has to be inserted after security-critical bounds check to stop the speculative execution. However, adding this to every bounds check has a significant performance overhead.

As NetSpectre is a network-based attack, it cannot only be prevented by mitigating Spectre but also through countermeasures on the network layer. A trivial NetSpectre attack can easily be detected by a DDoS protection, as multiple thousand identical packets are sent from the same source.

However, an attacker can choose any trade-off between packets per second and leaked bits per second. Thus, the speed at which bits are leaked can simply be reduced below the threshold that the DDoS monitoring can detect. This is true for any monitoring which tries to detect ongoing attacks, e.g., intrusion detection systems.

Although the attack is theoretically not prevented, at some point the attack becomes infeasible, as the time required to leak a bit increases drastically. Another method to mitigate NetSpectre is to add artificial noise to the network latency. As the number of measurements depends on the variance in network latency, additional noise requires an attacker to perform more measurements. Thus, if the variance in network latency is high enough, NetSpectre attacks become infeasible due to the large number of measurements required.

The post New NetSpectre Attack Does Not Require Victim to Download or Run Malicious Code appeared first on Appuals.com.