
Some thoughts on Spectre and Meltdown - cperciva
http://www.daemonology.net/blog/2018-01-17-some-thoughts-on-spectre-and-meltdown.html
======
pbsd
I'm gonna go and take issue with the claim that you were the first to come up
with microarchitectural attacks, and that their story begins in 2004:

\- Dan Page published [1] in 2002, describing an attack on DES exploiting
cache timings. In 2003, he published [2] describing countermeasures to this
class of attacks.

\- Concurrently, a Japanese team also attacked DES (and MISTY1) with cache
timing [3, 4].

\- Dan Bernstein published the first version of his AES cache timing attack in
late 2004 [5].

[1] [https://eprint.iacr.org/2002/169](https://eprint.iacr.org/2002/169)

[2]
[https://doi.org/10.1016/S1363-4127(03)00104-3](https://doi.org/10.1016/S1363-4127\(03\)00104-3)

[3]
[https://link.springer.com/chapter/10.1007/978-3-540-45238-6_...](https://link.springer.com/chapter/10.1007/978-3-540-45238-6_6)

[4]
[https://web.archive.org/web/20060906064630/http://web.engr.o...](https://web.archive.org/web/20060906064630/http://web.engr.oregonstate.edu/~aciicmez/osutass/data/Tsunoo02.pdf)

[5]
[https://cr.yp.to/antiforgery/cachetiming-20041121.pdf](https://cr.yp.to/antiforgery/cachetiming-20041121.pdf)

~~~
cperciva
_first to come up with microarchitectural attacks_

I'm not saying that. There are definitely earlier attacks which exploit
microarchitectural features (including caches).

What I am saying is that as far as I'm aware I'm the first person to
demonstrate an attack consisting of

1\. Information being leaked from a process into the microarchitectural state
of the CPU, followed by

2\. That information being retrieved by another process.

This is the model which the vast majority of attacks over the past decade have
followed, and it's the model which Spectre/Meltdown make use of.

~~~
pbsd
That's a much more defensible claim---one I have no issue with---but it was
easy to misread the post and believe it was claiming something more general.

~~~
cperciva
Thanks! It's getting late here (3 AM) so this might not be the best wording,
but would it help if I added a note after the third paragraph along the lines
of "Note that there have been previous side channel attacks which depended on
how microarchitectural features (usually caches) affected code execution; but
my work was the first to demonstrate information leaking from a program _into
the microarchitectural state_ and then being extracted from there." ?

(Feel free to suggest other wording too -- as I said, it's getting late here
and my word-putting-together skills are currently subpar.)

~~~
pbsd
That seems fine on its own, but it somewhat undermines the paragraph with "but
they have all followed the same basic mechanism", seeing as these earlier
attacks relying on caches etc did not follow this mechanism. Changing "all" to
"most" or "many" would probably suffice.

~~~
cperciva
Ah, that should have said over the _following_ years.

------
2trill2spill
> Google discovered a problem and reported it to Intel, AMD, and ARM on June
> 1st. Did they then go around contacting all of the operating systems which
> would need to work on fixes for this? Not even close. FreeBSD was notified
> the week before Christmas, over six months after the vulnerabilities were
> discovered.

Absolutely shitty behavior by Google, AMD, Intel and ARM. Notifying the
FreeBSD devs so late is a slap in the face to the FreeBSD community and makes
the internet as a whole less safe.

~~~
dotancohen
> Notifying the FreeBSD devs so late is a slap in the face to the FreeBSD
> community and makes the internet as a whole less safe.

Absolutely. That is quite the proper response to FreeBSD leaking privileged
information about vulnerabilities in the past.

~~~
2trill2spill
> Absolutely. That is quite the proper response to FreeBSD leaking privileged
> information about vulnerabilities in the past.

And what vulnerability leaks are you talking about?

~~~
rincebrain
They might be mixing up Free and OpenBSD, and thinking of [1], since I can't
find any obvious results for FBSD making that mistake.

[1] - [https://marc.info/?l=openbsd-
misc&m=150815942414653&w=2](https://marc.info/?l=openbsd-
misc&m=150815942414653&w=2)

~~~
cperciva
If that's what it was, they were both mixing up FreeBSD and OpenBSD and had a
time machine.

OpenBSD has been clear in the past about not respecting embargoes, however.
That's their right (Linus takes the same position) but I would completely
understand people deciding to not notify OpenBSD as a result.

But as far as I'm aware, FreeBSD has an exceptional track record when it comes
to respecting vulnerability embargoes.

------
alain94040
The analogies with the visa/passport are good, except the one about Meltdown:

 _Because she doesn 't have a North Korean visa, she (somehow) checks the
expiry date on someone else's North Korean visa, and then (if it is about to
expire) runs out to renew it_

Maybe try this version: she calls the embassy to ask if she needs to renew her
visa (which she doesn't have). The clerk, who has access to all the visas ever
issued, tells her that no one has a visa that expires in the next few months,
so she is good. This way, you find out about other people's expiration dates.

~~~
cperciva
I agree that analogy makes more sense, but I _wanted_ an analogy which
involved my girlfriend doing something impossible -- because a process
accessing memory it doesn't have permission to access is supposed to be
impossible.

------
niftich
These side-channel attacks -- which, as illustrated, are not new -- are
becoming perceived as more acute because more so than before we're
intermingling processes with vastly different purposes, responsibilities, and
origins, on the same hardware. When you do this, it's exceedingly difficult to
cloak intrinsic attributes of execution, such as cache timing, or even
execution timing, from other contexts of execution that have access to observe
enough facets of the system.

This applies at all levels of reading, really. We're mixing the trafficking of
sensitive authentication information in the same process as code that executes
instantly upon clicking on hyperlinks. We're mixing business and pleasure on
the same filesystem, in the same OS and memory space. We're mixing mutually
untrusting entities' private data and code on timesharing systems that we're
renting in someone else's datacenter.

Process boundaries, both in terms of physical reality and design choices on
what constitutes a system boundary, are critical, and will need additional
thought. At the same time, a boundary that's more robust to side-channel
attacks than most is having all the hardware exclusive to yourself.

Also, this entire issue neatly demonstrates the problems with executing
untrusted code. Solving the issue of vetting code and evaluating trust,
especially by average users, is extremely difficult; but the current culture
of the Web largely consists of running untrusted code immediately from a
single user-entered string, or through automatic or manual navigation
thenceforth. This is a frightening proposition, and yet entirely mainstream
today.

~~~
willtim
This problem is made worse by technologies like JavaScript, which resemble
system programming languages in the lack of restrictions placed on untrusted
code. JS code can create threads, sockets, timers, perform I/O, loop or
allocate forever. This is complete overkill for something that is mostly
needed for interactive websites. Web Assembly doesn't fix this problem either.
JavaScript has killed accessibility for the web and created numerous security
problems. I don't want it and try to block it when I can.

------
mhandley
In section 5.2 of Bernstein's paper, he discusses isolating single-source
transformations. His example is locking down jpegtopnm using standard Unix
mechanisms so it can only read stdin and write stdout and do absolutely
nothing else. It seems this pattern really should be one that is trivial for
the programmer to use, without having to go through the process of managing a
pool of UIDs, remember about setting process limits, etc. Then it might be
used correctly more often. Would be a useful building block for lots of code,
especially if it were portable across many versions of *nix.

~~~
cperciva
This is basically what Capsicum (FreeBSD + Linux) and pledge (OpenBSD) are
for. I agree that it would be nice to have a standard interface, but the
functionality provided by those is sufficiently different that it's hard to
imagine how a single API could be created which usefully covers both.

~~~
bringtheaction
Speaking of which, anyone have examples of how to restrict a process to using
stdin and stdout only with Capsicum and pledge?

------
antirez
On the topic of explaining Spectre and Meltdown to non technical audience,
this is my try (in Italian but Google Translate does a reasonable
translation): [https://medium.com/@antirez/spectre-e-meltdown-spiegati-
al-m...](https://medium.com/@antirez/spectre-e-meltdown-spiegati-al-mio-
idraulico-cd4567ce6991)

The reason why I thought it's so important to do this effort is that, this bug
was in the news for days, everybody is going to do upgrades in one way or the
other, and even to pay for the performance cost, yet most of the people out
there will not understand what it is about. I've the feeling that this
disconnects non technical people from technology in a very bad way. That's the
reason I believe that divulgation is so crucial.

------
mappu
Are those earlier-mentioned attacks against HyperThreading and caches still
viable? If not, were they resolved in OpenSSL, in the OS, or in hardware?

~~~
cperciva
The particular code path which I found was leaking information was fixed in
OpenSSL. Some operating systems (including FreeBSD) turned off HyperThreading
by default for a while to allow software authors to fix their code, and then
re-enabled it again a few years later.

Intel stopped using HyperThreading for a while (it was in the Pentium 4, but
that architecture was abandoned), and also made some changes to the caches
which they _claimed_ would help, but they never provided any details and I've
never seen any verification of their claims in that regard. (Obviously
whatever changes they made weren't enough to prevent the Spectre and Meltdown
attacks conveying information through the cache!)

So the best summary is that people threw up their hands and said "yeah, it's a
problem, let's hope that nobody writes code which leaks any sensitive
information into the microarchitectural state". Not exactly a good position to
be in...

------
Maken
> For my Tarsnap online backup service I compile and cryptographically sign
> the packages on a system which has never been connected to the Internet.
> Before I turned it on for the first time, I opened up the case and pulled
> out the wifi card; and I copy files on and off the system on a USB stick.

How can you be sure the system you copied those files from is not compromised,
the micro-controller on the USB stick has not been compromised, and now it's
not going to take control of the build system and replace the compiler chain
with a modified one which will make all your software vulnerable?

~~~
cperciva
I can't. Having an airgapped system doesn't solve every problem; but it does
solve _some_ of them.

------
mickster99
Good write up. The following blurb got me thinking:

"In the industry we refer to "airgapped" systems; this is a reference back to
the days when connecting to a network required wires, so if there was a
literal gap with just air between two systems, there was no way they could
communicate."

If we know the Internet is a scary place why do nuclear plants, power plants,
etc. have Internet connectivity?

~~~
MrRadar
Because it's the most efficient way to communicate with the corporate
headquarters and clients/customers? These places are fundamentally businesses
and they have the same communication needs as any other.

------
mozumder
If you're worried about servers being cracked, the best thing is to avoid
shared cloud servers and use dedicated private servers.

These attacks rely on some other user-process malware running on the server to
gain information via side channels. If every process in your server is your
own, for your web services or whatever, you don't have to worry about it.

As usual, nothing beats dedicated private servers.

~~~
yeukhon
If you plan to run one VM on one physical machine, perhaps you don’t have to
worry your neighbor reading your data. But a malicious program running on your
machine CAN still exploit the bugs. In fact one can exploit the browrser via
Javascript by taking advantage of Spectre. There is no way to avoid the
vulnerabilities until you have patchrd your system and your software. The
three bugs we know of is not a cloud vs dedicated choice.

~~~
snaky
> a malicious program running on your machine

If a malicious program could make the way to the private server, the problem
is much worse than side-channel attacks.

> the browrser via Javascript

Server. We are talking about server.

~~~
baq
If your server does eh scraping, it'd better not have access to your network.

~~~
snaky
Yes, 'active' (JS-running) web scraping is an obvious exception.

------
shishiwakamaru1
I've read the ppapers and lots of articles on the subject and still can't get
how do I know where I land using Spectre Variante 1. I know I can read some
byte in Memory, but do I know where exactly it comes from? I know that I can
increase the x value so that I can read other values, but until which point?
Thanks

