[GTALUG] ret2spec: Speculative Execution Using Return Stack Buffers

Russell Reiter rreiter91 at gmail.com
Thu Aug 9 15:49:20 EDT 2018


On Thu, Aug 9, 2018, 2:35 PM David Collier-Brown via talk <talk at gtalug.org>
wrote:

> 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
>
>
> On 2018-08-09 10:03 a.m., Russell Reiter via talk wrote:
>
> 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).
>
> ---
> Talk Mailing Listtalk at gtalug.orghttps://gtalug.org/mailman/listinfo/talk
>
>
> --
> David Collier-Brown,         | Always do right. This will gratify
> System Programmer and Author | some people and astonish the restdavecb at spamcop.net           |                      -- Mark Twain
>
> ---
> Talk Mailing List
> talk at gtalug.org
> https://gtalug.org/mailman/listinfo/talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gtalug.org/pipermail/talk/attachments/20180809/81f3a486/attachment.html>


More information about the talk mailing list