NetSpectre - speculative execution side-channel attack over local network

Solution In Progress - Updated -

Environment

  • Red Hat Enterprise Linux 5
  • Red Hat Enterprise Linux 6
  • Red Hat Enterprise Linux 7
  • Red Hat OpenStack Platform
  • Red Hat Virtualization

Issue

I've read Internet articles that describe a problem called "NetSpectre".
I have security concerns around side-channel attacks.

Resolution

“NetSpectre: Read Arbitrary Memory over Network” is the first concept of spectre variant-1 that abuses speculative execution across a network. It allows a remote attacker to exploit spectre “gadgets” available in the code path that are accessible in the operating system's network stack. The attacker sends a series of crafted requests to the target system and measures response times. These response times allow the attacker to then deduce a secret value from the victim's memory.

NetSpectre is the first access-driven, remote-cache attack (Evict+Reload) over a network, and requires two gadgets to be available to the attacker, either in user space or kernel space. These gadgets are:

  • Leak gadget - Accesses a stream at an attacker-controlled location.
  • Transmit gadget - Performs an arbitrary operation where the results depend on the micro-architectural state modified by the leak gadget.

The proof of concept uses a widget which leaks approximately 60 bits/hr over a span of 100,000 packets. Although 60 bits/hr seems small, this leak can assist in a chain of attacks which can lead to further privilege escalation. Leaking small amounts of data can be used to defeat Address Space Layout Randomization (ASLR) if an attacker has advanced knowledge of software versions used on the system.

Root Cause

This attack leverages a new “side channel” of AVX2 instructions (x86 only) which opens a new attack vector that has not been used by existing spectre exploits.

Reconnaissance

  • An attacker would need to know the target system's architecture and software versions. Having access to matching binaries allows an attacker to better understand the target system's memory layout.
  • The attacker would also need to measure a large sample of network latency, between the system to be attacked and the attacker; this sample is used as the baseline for determining whether a value is in the cache. One article source states that “around 100,000 measurements are required to reduce the noise to a level where a difference between bits can be clearly seen” and further, that in non-ideal situations of higher network latency and variations in hardware and system load they "increased the number of measurements by a factor of 20" (that is, each bit was measured 20,000,000 times).

Attack vectors
This particular exploit uses local network interfaces to exfiltrate data. The attack data may not need to transmit across a physical network and could be transmitted across a virtual network between virtual machines on the same host.

Red Hat has filed a bug for NetSpectre

Diagnostic Steps

Patches have already been released for all currently shipped products to harden the kernel against spectre v1-style attacks (see CVE-2017-5753). This hardening removes the primary leak gadget, thereby minimising its use as a NetSpectre attack vector. Ensure your system has been updated to use the latest kernel patches.

Mitigation
This attack method's reliability is reduced if:

  • The memory area being attacked is userspace and the process is restarted.
  • The system is rebooted.
  • The system being attacked is behind a load balancer.

Additionally, the following strategies can be used to lower the impact or scope of this flaw:

  • Allow only trusted users and IP addresses to access remotely accessible services like SSH, LDAP, or SNMP.
  • Configure firewalls and some services to limit the amount of traffic per source IP address (because the attack involves sending a large number of packets to a particular service running on a port).
  • Actively monitor excessive or invalid traffic from a particular IP address, especially in a short time interval. Some IDS devices or software can actively block strange data.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

Comments