[GTALUG] ret2spec: Speculative Execution Using Return Stack Buffers

[David Collier-Brown]

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>