[GTALUG] ret2spec: Speculative Execution Using Return Stack Buffers

[Russell Reiter via talk]

More Intel woes.

http://www.digitaljournal.com/tech-and-science/technology/new-security-flaw-with-intel-processors/article/529077

Quote from the whitepaper link in the article.

3 GENERAL ATTACK OVERVIEW

Before detailing specific attack scenarios, in this section, we introduce
the basics of how RSB-based speculative execution can be achieved and be
abused. We explore whether and how attackers may manipulate the RSB entries
in order to leak sensitive data using speculative execution that they could
not access otherwise. Similar to recent microarchitectural attacks [8, 10,
22, 26, 29], we trick the CPU to execute instructions that would not have
been executed in a sequential execution. The goal is to leak sensitive
information in speculation, e.g., by caching a certain memory area that can
be detected in a normal (non-speculative) execution. The general idea of
our attack can be divided into three steps:

(A1) trigger misspeculations in the return address predictor, i.e., enforce
that returns mispredict

(A2) divert the speculative execution to a known/controlled code sequence
with the required context

(A3) modify the architectural state in speculation, such that it can be
detected from outside

(A1) Triggering Misspeculation: From an attacker’s perspective, enforcing
that the return predictor misspeculates upon function return is essential
to reliably divert speculative execution to attacker-controlled code (see
A2 for how to control the speculated code). Misspeculations can be achieved
in several ways, depending on the RSBs underflow behavior (as discussed in
Section 2.3).

[David Collier-Brown via talk]

For any instruction that can be executed during speculation, if it has
an effect, it's arguably usable as a covert channel (;-))

--dave

Post by Russell Reiter via talk
More Intel woes.
http://www.digitaljournal.com/tech-and-science/technology/new-security-flaw-with-intel-processors/article/529077
Quote from the whitepaper link in the article.
3 GENERAL ATTACK OVERVIEW
Before detailing specific attack scenarios, in this section, we
introduce the basics of how RSB-based speculative execution can be
achieved and be abused. We explore whether and how attackers may
manipulate the RSB entries in order to leak sensitive data using
speculative execution that they could not access otherwise. Similar to
recent microarchitectural attacks [8, 10, 22, 26, 29], we trick the
CPU to execute instructions that would not have been executed in a
sequential execution. The goal is to leak sensitive information in
speculation, e.g., by caching a certain memory area that can be
detected in a normal (non-speculative) execution. The general idea of
(A1) trigger misspeculations in the return address predictor, i.e.,
enforce that returns mispredict
(A2) divert the speculative execution to a known/controlled code
sequence with the required context
(A3) modify the architectural state in speculation, such that it can
be detected from outside
(A1) Triggering Misspeculation: From an attacker’s perspective,
enforcing that the return predictor misspeculates upon function return
is essential to reliably divert speculative execution to
attacker-controlled code (see A2 for how to control the speculated
code). Misspeculations can be achieved in several ways, depending on
the RSBs underflow behavior (as discussed in Section 2.3).
---
Talk Mailing List
https://gtalug.org/mailman/listinfo/talk

[Russell Reiter via talk]

For any instruction that can be executed during speculation, if it has an
effect, it's arguably usable as a covert channel (;-))

Welcome to a web world of "jittery" java. Hardening against accurate timers
seems like an oxymoron to me. On second thought tho, it does all start with
military intelligence, so it must be a natural evolution.

"Mozilla Foundation: The Mozilla Foundation likewise acknowledged the
issue. They decided to refrain from using compiler-assisted defenses, as
they would seemingly require complex changes to JIT-compiled and C++ code.
Instead, they aim to remove all (fine-granular) timers from Firefox to
destroy caching-based feedback channels. Furthermore, they referred to an
upcoming Firefox release that includes time jittering features similar to
those described in FuzzyFox [23], which further harden against accurate
timers.

Google: Google acknowledged the problem in principle also affects Chrome.
Similar to Firefox, they do not aim to address the problem with
compiler-assisted solutions. Instead, they also refer to inaccurate timers,
but more importantly, focus on a stronger isolation between sites of
different origins. Chrome’s so-called Site Isolation prevents attackers
from reading across origins (e.g., sites of other domains). However, as
discussed in Section 6.1, this does not mitigate the problem that attackers
can break ASLR with our attack technique."

--dave
More Intel woes.
http://www.digitaljournal.com/tech-and-science/technology/new-security-flaw-with-intel-processors/article/529077
Quote from the whitepaper link in the article.
3 GENERAL ATTACK OVERVIEW
Before detailing specific attack scenarios, in this section, we introduce
the basics of how RSB-based speculative execution can be achieved and be
abused. We explore whether and how attackers may manipulate the RSB entries
in order to leak sensitive data using speculative execution that they could
not access otherwise. Similar to recent microarchitectural attacks [8, 10,
22, 26, 29], we trick the CPU to execute instructions that would not have
been executed in a sequential execution. The goal is to leak sensitive
information in speculation, e.g., by caching a certain memory area that can
be detected in a normal (non-speculative) execution. The general idea of
(A1) trigger misspeculations in the return address predictor, i.e.,
enforce that returns mispredict
(A2) divert the speculative execution to a known/controlled code sequence
with the required context
(A3) modify the architectural state in speculation, such that it can be
detected from outside
(A1) Triggering Misspeculation: From an attacker’s perspective, enforcing
that the return predictor misspeculates upon function return is essential
to reliably divert speculative execution to attacker-controlled code (see
A2 for how to control the speculated code). Misspeculations can be achieved
in several ways, depending on the RSBs underflow behavior (as discussed in
Section 2.3).
---
--
David Collier-Brown, | Always do right. This will gratify
---
Talk Mailing List
https://gtalug.org/mailman/listinfo/talk

[David Collier-Brown via talk]

Multics and the Sun T-series did it right: check the permissions before
letting an action complete.
Interestingly, the authors of the DPS8m simulator had to scratch their
head a bit to make sure an intel chipset wouldn't subvert the emulator's
checks (;-))

--dave

On Thu, Aug 9, 2018, 2:35 PM David Collier-Brown via talk
For any instruction that can be executed during speculation, if it
has an effect, it's arguably usable as a covert channel (;-))
Welcome to a web world of "jittery" java. Hardening against accurate
timers seems like an oxymoron to me. On second thought tho, it does
all start with military intelligence, so it must be a natural evolution.
"Mozilla Foundation: The Mozilla Foundation likewise acknowledged the
issue. They decided to refrain from using compiler-assisted defenses,
as they would seemingly require complex changes to JIT-compiled and
C++ code. Instead, they aim to remove all (fine-granular) timers from
Firefox to destroy caching-based feedback channels. Furthermore, they
referred to an upcoming Firefox release that includes time jittering
features similar to those described in FuzzyFox [23], which further
harden against accurate timers.
Google: Google acknowledged the problem in principle also affects
Chrome. Similar to Firefox, they do not aim to address the problem
with compiler-assisted solutions. Instead, they also refer to
inaccurate timers, but more importantly, focus on a stronger isolation
between sites of different origins. Chrome’s so-called Site Isolation
prevents attackers from reading across origins (e.g., sites of other
domains). However, as discussed in Section 6.1, this does not mitigate
the problem that attackers can break ASLR with our attack technique."
--dave

Post by Russell Reiter via talk
More Intel woes.
http://www.digitaljournal.com/tech-and-science/technology/new-security-flaw-with-intel-processors/article/529077
Quote from the whitepaper link in the article.
3 GENERAL ATTACK OVERVIEW
Before detailing specific attack scenarios, in this section, we
introduce the basics of how RSB-based speculative execution can
be achieved and be abused. We explore whether and how attackers
may manipulate the RSB entries in order to leak sensitive data
using speculative execution that they could not access otherwise.
Similar to recent microarchitectural attacks [8, 10, 22, 26, 29],
we trick the CPU to execute instructions that would not have been
executed in a sequential execution. The goal is to leak sensitive
information in speculation, e.g., by caching a certain memory
area that can be detected in a normal (non-speculative)
execution. The general idea of our attack can be divided into
(A1) trigger misspeculations in the return address predictor,
i.e., enforce that returns mispredict
(A2) divert the speculative execution to a known/controlled code
sequence with the required context
(A3) modify the architectural state in speculation, such that it
can be detected from outside
(A1) Triggering Misspeculation: From an attacker’s perspective,
enforcing that the return predictor misspeculates upon function
return is essential to reliably divert speculative execution to
attacker-controlled code (see A2 for how to control the
speculated code). Misspeculations can be achieved in several
ways, depending on the RSBs underflow behavior (as discussed in
Section 2.3).
---
Talk Mailing List
https://gtalug.org/mailman/listinfo/talk

--
David Collier-Brown, | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
---
Talk Mailing List
https://gtalug.org/mailman/listinfo/talk