[GTALUG] ret2spec: Speculative Execution Using Return Stack Buffers
David Collier-Brown
davec-b at rogers.com
Thu Aug 9 17:18:59 EDT 2018
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 2018-08-09 3:49 p.m., Russell Reiter wrote:
>
> On Thu, Aug 9, 2018, 2:35 PM David Collier-Brown via talk
> <talk at gtalug.org <mailto: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 List
>> talk at gtalug.org <mailto:talk at gtalug.org>
>> 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
> davecb at spamcop.net <mailto:davecb at spamcop.net> | -- Mark Twain
>
> ---
> Talk Mailing List
> talk at gtalug.org <mailto:talk at gtalug.org>
> 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
davecb at spamcop.net | -- Mark Twain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gtalug.org/pipermail/talk/attachments/20180809/f01eea52/attachment.html>
More information about the talk
mailing list