Good read on the subject. With exploit code examples.

https://react-etc.net/entry/exploiting-speculative-execution-meltdown-spectre-via-javascript

Looks like anybody who has still enabled js will be p0wned
pretty fast and easy, regardless of browser or os.

Lets see how quick the first metasploit module will show
up.

-------snip--------------------------

Exploiting Speculative Execution (Meltdown/Spectre) via
JavaScript

The critical vulnerabilities found in Intel and other CPUs
represent a significant security risk. Because the flaw is
so low level, the usual protections that web developers are
used to don't apply. Even sandboxed JavaScript code can be
used to exploit the vulnerabilities known as Meltdown and
Spectre.

The issue affects Intel CPUs broadly, but also AMD and
various ARM processors are suspect to a similar attack.
Browser vendors have already started mitigating the issue
with Microsoft, for example announcing improvements to
Internet Explorer and Microsoft Edge browsers against
Speculative Execution. Mozilla has also taken action against
the new class of timing attacks and Chromium based browers a
fix is scheduled for version 64. The WebKit team also did a
writeup on the implications of Spectre and Meltdown in their
blog.

Due to the dynamic nature of the browser (and the OS market
in general) it will be virtually impossible to patch all
browsers. This means that web services are threathened from
an unusual attack vector developers really can't protect
from, but thankfully most browsers are now evergreen
(auto-updating) which means fixes will be applied to
contemporary devices in active use.

For Chromium based browsers such as Opera and Google Chrome
users can improve security with a feature known as Site
Isolation, and in general the lucky aspect is that the flaw
is so low level that it is not trivial to exploit it to gain
access to passwords or other sensitive data on a large
scale. Popular web applications like WordPress are a much
more uniform target than a complete Operating System.

There is already some examples online for exploiting CPU
speculative execution using JavaScript - complete with
explanation of the disassembly for the said code. Such an
example of vulnerable JavaScript is shown below, an excerpt
of the paper on Spectre attacks:

JavaScript exploit of Speculative Execution
(Meltdown/Spectre)

This marks a significant event not only for the OS market,
but for the developers in general. Where as web developers
are used to working in an environment virtually impossible
to cause havoc on Operating System level - the CPU bug
announced in early 2018 breaks this heyday. Spectre and
Meltdown JavaScript exploits affects all browsers across
different operating systems.

To follow up on patch statuses for Windows, Android, macOS,
iOS, Linux Distributions like Debian, Ubuntu and RedHat
Operating systems as well as other significant tools you can
check out a Github repositor showing a summary of Meltdown /
Spectre Patches centrally: meltdownspectre-patches

More details of a similar vector can be read from a research
paper on Practical Keystroke Timing Attacks in Sandboxed
JavaScript from Austrian Graz University of Technology:
https://misc0110.net/web/files/keystroke_js.pdf
Posted on RetroBBS II

To: Anonymous
On 01/10/2018 04:32 PM, Anonymous wrote:
> Good read on the subject. With exploit code examples.
>
> https://react-etc.net/entry/exploiting-speculative-execution-meltdown-spectre-via-javascript
>
>
> Looks like anybody who has still enabled js will be p0wned
> pretty fast and easy, regardless of browser or os.
>
> Lets see how quick the first metasploit module will show
> up.
>
> -------snip--------------------------
>
> Exploiting Speculative Execution (Meltdown/Spectre) via
> JavaScript
>
> The critical vulnerabilities found in Intel and other CPUs
> represent a significant security risk. Because the flaw is
> so low level, the usual protections that web developers are
> used to don't apply. Even sandboxed JavaScript code can be
> used to exploit the vulnerabilities known as Meltdown and
> Spectre.
>
> The issue affects Intel CPUs broadly, but also AMD and
> various ARM processors are suspect to a similar attack.
> Browser vendors have already started mitigating the issue
> with Microsoft, for example announcing improvements to
> Internet Explorer and Microsoft Edge browsers against
> Speculative Execution. Mozilla has also taken action against
> the new class of timing attacks and Chromium based browers a
> fix is scheduled for version 64. The WebKit team also did a
> writeup on the implications of Spectre and Meltdown in their
> blog.
>
> Due to the dynamic nature of the browser (and the OS market
> in general) it will be virtually impossible to patch all
> browsers. This means that web services are threathened from
> an unusual attack vector developers really can't protect
> from, but thankfully most browsers are now evergreen
> (auto-updating) which means fixes will be applied to
> contemporary devices in active use.
>
> For Chromium based browsers such as Opera and Google Chrome
> users can improve security with a feature known as Site
> Isolation, and in general the lucky aspect is that the flaw
> is so low level that it is not trivial to exploit it to gain
> access to passwords or other sensitive data on a large
> scale. Popular web applications like WordPress are a much
> more uniform target than a complete Operating System.
>
> There is already some examples online for exploiting CPU
> speculative execution using JavaScript - complete with
> explanation of the disassembly for the said code. Such an
> example of vulnerable JavaScript is shown below, an excerpt
> of the paper on Spectre attacks:
>
> JavaScript exploit of Speculative Execution
> (Meltdown/Spectre)
>
> This marks a significant event not only for the OS market,
> but for the developers in general. Where as web developers
> are used to working in an environment virtually impossible
> to cause havoc on Operating System level - the CPU bug
> announced in early 2018 breaks this heyday. Spectre and
> Meltdown JavaScript exploits affects all browsers across
> different operating systems.
>
> To follow up on patch statuses for Windows, Android, macOS,
> iOS, Linux Distributions like Debian, Ubuntu and RedHat
> Operating systems as well as other significant tools you can
> check out a Github repositor showing a summary of Meltdown /
> Spectre Patches centrally: meltdownspectre-patches
>
> More details of a similar vector can be read from a research
> paper on Practical Keystroke Timing Attacks in Sandboxed
> JavaScript from Austrian Graz University of Technology:
> https://misc0110.net/web/files/keystroke_js.pdf
> Posted on RetroBBS II

Here's a writeup recently posted to an FMS group (credit to Hagbard for
posting):

Here's a nice and simple explanation of the issues:

Spectre & Meltdown: tapping into the CPU's subconscious thoughts
Posted on 2018, Jan 06

Comments are very welcome on bert.hubert@powerdns.com or
@PowerDNS_Bert. Update: several constructive remarks have been used to
improve this text. Thanks!

In this post I will attempt to fully explain the Spectre and Meltdown
vulnerabilities in an accessible way. I decided to write it up after I
realised it took me more than a day to figure it out, even though I’ve
been doing security related stuff on CPUs for 20 years.

You will find many explanations of Meltdown elsewhere. This document is
as far as I know the only one so far that makes the hardest part of
Spectre accessible.

After reading the story below, the most excellent and detailed
Google-provided explanations should start to make sense. The Spectre
and Meltdown papers are also great sources of information.

Nothing I write here is original. The researchers involved deserve huge
credit for their work. My explanation here is a small tribute to their
massive achievement.

Please contact me if you find any mistakes in this post, but do realise
that this post is a tradeoff between ‘accessible’ and ‘comprehensive’.
In other words, some shortcuts have been taken.

Out-of-order execution

To a remarkable extent, computer programs are like kitchen recipes. The
CPU can then be seen as a machine that executes those recipes.

Over the years, it has proven hard to make the clock speeds of CPUs go
up any further. A few gigahertz is the practical limit. To improve
speeds, we can’t make individual things go a lot faster, much like you
can’t whip cream any faster by upping the voltage on your food
processor.

When faced with a recipe like this:

Seed and dice a pumpkin, chop into cubes
Cook for 5 minutes in melted butter
Blend cubes in food processor
Put chicken in a Dutch oven at 180 degrees for 3 hours
Make chicken broth
Add broth to blender until pumpkin soup reaches desired consistency

A wise cook immediately spots that the preparation of the chicken can
fully run in parallel with the pumpkin related work. And in fact, we’ll
begin by making the chicken & dice the pumpkin while the chicken is in
the oven.

CPUs do similar things for us to improve processing speeds. While on
the surface a CPU executes code sequentially, if it spots that there is
work ‘down the road’ that could already be performed, it will do so in
the background and in parallel. However, and this is key, it will not
tell us about this.

From the perspective of an executing computer program, what the CPU
delivers is like pure magic. All of a sudden there is a whole bit of
code that takes no further time to execute: the results fall right out
of the sky.

Compared to the recipe above, it is like after preparing the pumpkin..
suddenly a fully cooked chicken appears. It was prepared in the
background, and we didn’t see it happening.

The CPU’s subconscious work

As computer programs execute, CPUs continually race ahead to perform
this “speculative” or “out-of-order” execution”. Sometimes it works and
it turns out the CPU can meaningfully get ahead, but frequently this
turns out not to be the case.

Compared to the recipe above, let’s say there was a step ‘now drip some
pumpkin blend over the chicken’, it would all have broken down:
suddenly you can’t cook the chicken before the pumpkin is done. The
speculation failed.

To make this not be a problem for a CPU, the promise is that all this
speculative execution leaves no trace. The assumption is that if it
failed, it was like the attempt was never made. All effects are rolled
back.

This assumption, which turns out to be false, is key to understanding
Meltdown/Spectre.

The cache

Regular RAM memory is a lot slower than a CPU, so it makes sense to
have a cache for frequently used memory. This is highly effective, to
the point that a modern CPU will actually not use memory directly at
all. It will always go through the cache. If a bit of memory was
already found in the cache, accessing it will go hugely faster than if
that memory first had to be retrieved from actual RAM.

But what about the promise that speculative execution left no trace?
What if some code that was executed already had to access memory,
surely this would end up in the cache? Isn’t that a trace?

Turns out that this is indeed the case - the CPU has no alternative. To
(speculatively) execute code that needs information from RAM, it has to
go through the cache.

The upshot of this is that we have gained a facility to figure out what
the CPU has been doing behind our backs, things we were never supposed
to see.

Forbidden memory

An advertisement running on a webpage should not have access to the
rest of the computer. Otherwise a single rogue ad could sniff your WiFi
password & share it with the world. And beyond that, an ad may need
access to the page on which it is displayed, but it should not be able
to look into other browser tabs.

In short, we use programming and CPU features to restrict what data
running code can read, in order to protect our secrets.

Key to both Meltdown and Spectre is that we trick the CPU into
speculatively executing code that does read forbidden memory.