Malware Can Exploit New Flaw in Intel CPUs to Launch Side-Channel Attacks

A new research has yielded yet another means to pilfer sensitive
data by exploiting what’s the first “on-chip, cross-core”
side-channel in Intel Coffee Lake and Skylake processors.

Published by a group of academics from the University of
Illinois at Urbana-Champaign, the findings^[1] are expected to be
presented at the USENIX Security Symposium coming this August.

While information leakage attacks targeting the CPU
microarchitecture have been previously demonstrated to break the
isolation between user applications and the operating system,
allowing a malicious program to access memory used by other
programs (e.g., Meltdown and Spectre), the new attack leverages a
contention on the ring interconnect.

SoC Ring interconnect^[2]
is an on-die bus arranged in a ring topology which enables
intra-process communication between different components (aka
agents) such as the cores, the last level cache (LLC), the graphics
unit, and the system agent that are housed inside the CPU. Each
ring agent communicates with the ring through what’s called a ring
stop.

To achieve this, the researchers reverse-engineered the ring
interconnect’s protocols to uncover the conditions for two or more
processes to cause a ring contention, in turn using them to build a
covert channel with a capacity of 4.18 Mbps, which the researchers
say is the largest to date for cross-core channels not relying on
shared memory, unlike Flush+Flush or Flush+Reload^[3].

“Importantly, unlike prior attacks, our attacks do not rely on
sharing memory, cache sets, core-private resources or any specific
uncore^[4]
structures,” Riccardo Paccagnella, one of the authors of the study,
said^[5]. “As a consequence, they
are hard to mitigate using existing ‘domain isolation’
techniques.”

Observing that a ring stop always prioritizes traffic that is
already on the ring over new traffic entering from its agents, the
researchers said a contention occurs when existing on-ring traffic
delays the injection of new ring traffic.

Armed with this information, an adversary can measure the delay
in memory access associated with a malicious process due to a
saturation of bandwidth capacity caused by a victim process’ memory
accesses. This, however, necessitates that the spy process
consistently has a miss in its private caches (L1-L2) and performs
loads from a target LLC slice.

In doing so, the repeated latency in memory loads from LLC due
to ring contention can allow an attacker to use the measurements as
a side-channel to leak key bits from vulnerable EdDSA, and RSA
implementations as well as reconstruct passwords by extracting the precise timing of
keystrokes^[6] typed by a victim
user.

Specifically, “an attacker with knowledge of our reverse
engineering efforts can set itself up in such a way that its loads
are guaranteed to contend with the first process’ loads, […] abuses mitigations to preemptive scheduling cache attacks to cause
the victim’s loads to miss in the cache, monitors ring contention
while the victim is computing, and employs a standard machine
learning classifier to de-noise traces and leak bits.”

The study also marks the first time a contention-based
microarchitectural channel has been exploited for keystroke timing
attacks to infer sensitive data typed by the victim.

In response to the disclosures, Intel categorized the attacks as
a “traditional side channel,” which refers to a class of oracle attacks^[7]
that typically take advantage of the differences in execution
timing to infer secrets.

The chipmaker’s guidelines^[8]
for countering timing attacks against cryptographic implementations
recommend adhering to constant time programming principles by
ensuring that —

• Runtime is independent of secret values
• The order in which the instructions are executed (aka code
  access patterns) are independent of secret values, and
• The order in which memory operands are loaded and stored (data
  access patterns) are independent of secret values

Additional guidance on safe development practices to mitigate
traditional side-channel attacks can be found here^[9]. The source code to
reproduce the experimental setup detailed in the paper can be
accessed here^[10].