
CacheOut: Leaking Data on Intel CPUs via Cache Evictions - beefhash
https://cacheoutattack.com/
======
jnordwick
Before people get all nutty as usual:

This is another TSX (transactional memory) issue, and you can disable TSX
without much of a problem.

The attacker basically needs to be running a binary on the machine (not JS in
a browser or anything).

The leakage is extremely slow, about 225 byte/minute for ASCII text (a 4k page
in 18 minutes). I'm not sure if that was an exact recovery either, just a
probabilistic one. With noise reduction to enhance recovery, they said it took
twice as long - so about 113 byte/minute.

It seems to be able to only be able to control the bottom 12-bits of the
address to recover (but I didn't fully get why) and require the process to be
either reading or writing the data to get it into L1 cache somehow, so just
sitting in RAM isn't good enough.

attacker still needs to figure out an address (even with ASLR there is still a
lot of guessing, and if you have really sensitive data, just move it every
second until you wipe it).

Interesting, but kind of a non-issue.

~~~
jandrese
That's a lot of work, but the instant it's in a rootkit everybody will be able
to do it. 113 bytes is extracting an AES key from memory in about a minute.

It's only really hard and messy for the first guy who implements it, after
that it is much easier, albeit still fairly messy. I'm not saying we need to
panic, but it's more than a "non-issue".

~~~
userbinator
_113 bytes is extracting an AES key from memory in about a minute._

How do you know where the key is, and how are you guaranteed to be able to
read enough of it before the "shifting sands" that is timing unpredictability
and general noise in the system make you read something else?

That's what really irritates me about all these side-channels that have been
found ever since the first Spectre/Meltdown --- they all demonstrate something
flashy like "we read a key/password/secret/something important from memory in
a few minutes" while conveniently ignoring to mention the countless hours
spent aligning everything just right so they could show off the one "magic
trick". In a lot of the cases there's barely even any control over where it
reads.

Every time something like this comes up, I feel compelled to post some bytes
from somewhere random in the memory of a random process on my machine to show
just how much I care; here you go:

    
    
        E8 7F 00 00 00 A1 64 30 40 00 89 45 D8 8D 45 D8
        C4 20 00 00-CE 20 00 00-D8 20 00 00-E2 20 00 00
        F8 20 00 00-00 21 00 00-0E 21 00 00-16 21 00 00
        26 21 00 00-36 21 00 00-42 21 00 00-56 21 00 00
        66 21 00 00-76 21 00 00-84 21 00 00-96 21 00 00
        AA 21 00 00-00 00 00 00-FF FF FF FF-B4 16 40 00
        C8 16 40 00-7C 20 00 00-00 00 00 00-00 00 00 00
        EC 20 00 00-00 20 00 00-00 00 00 00-00 00 00 00
    

Of course if you are being targeted then the concern may go up, but I still
think that attackers would have lower-hanging-fruit than this, seeing as
setting up one of these reads to get _one_ secret would itself require such
intimate knowledge of your machine's configuration and state that they
probably already know what they want.

~~~
zelon88
What is it that programmers do? They automate complex tasks that take humans
considerable effort.

If a university can accomplish this task with their funding and no urgent
incentive, what is the nation state actor doing with their enormous budget?

~~~
jacquesm
The conventional wisdom is that if a nation state wants your data badly enough
it is game over. Even an air gap can apparently be bridged if you have the
budget and you're patient and smart enough. It's root kits, booters,
ransomware, exfiltration and script kiddies that you have to worry about in
practice.

~~~
zelon88
It's not what a nation does to it's own supply chain that a nations supply
chain has to worry about.

------
scandinavian
>CacheOut violates the operating system's privacy by extracting information
from it that facilitates other attacks, such as buffer overflow attacks.

>More specifically, modern operating systems employ Kernel Address Space
Layout Randomization (KASLR) and stack canaries. KASLR randomizes the location
of the data structures and code used by the operating system, such that the
location is unknown to an attacker. Stack canaries put secret values on the
stack to detect whether an attacker has tampered with the stack. CacheOut
extracts this information from the operating system, essentially enabling full
exploitation via other software attacks, such such as buffer overflow attacks.

Can anyone explain this scenario? Is this really a realistic scenario? Do they
mean if you have code execution on a system, and want to escalate privileges,
you would find another network/socket service that is running on the same
system, find an exploit in this service, and then leak the stack canary to
allow corrupting the stack? There's often easier ways to defeat the stack
canary.

~~~
loeg
Yes, it's a local privilege escalation issue, i.e. you must have local code
execution first. Leaking KASLR/stack canary just mean you get 90s level
triviality of attacking any stack-overflowing API you can find. Without this
bug, if you found a stack-overflow you could trigger from your local
unprivileged code, the target would likely detect the overflow due to the
canary. If you defeated that mechanism, constructing shellcode might be more
difficult due to (K)ASLR. With this bug, neither stack canaries nor (K)ASLR
are effective defenses against unprivileged programs.

~~~
scandinavian
Sure, I was just kinda confused that this was the example they presented. I
guess for highly targeted attacks, it might be somewhat useful.

>Leaking KASLR/stack canary just mean you get 90s level triviality of
attacking any stack-overflowing API you can find.

It does not seem trivial with this exploit, but maybe I'm just not getting it.
With the low accuracy and transfer rate, it seems like a lot of stars need to
line up with regards to how the service you attack function.

------
kohtatsu
Did AMD design their processors with these side channel attacks in mind, or is
it a matter of where the security research is focused?

~~~
makomk
Mostly, it seems to be a difference in design philosphy - AMD processors
prevent speculative reads of data that shouldn't be accessible almost
everywhere, whereas Intel ones allow them pretty much everywhere. This
particular attack requires TSX which AMD processors don't have, but I don't
think it'd work on AMD processors anyway because they're not missing the
security check that Intel ones are. If I remember rightly, there were other
now-mitigated exploits for this line fill buffer leak that didn't require TSX.

(The one exception is also interesting. AMD processors allow speculative reads
past the end of x86 segments and past BOUND instructions, which of course no-
one uses these days. This suggests there may have been a deliberate decision
to block them in the more important cases.)

~~~
temac
It is known since... forever?, that one should not speculate across security
boundaries. This was not enough to avoid Spectre, but this was largely enough
to avoid TONS of security vulns Intel is also susceptible to.

Somebody messed-up big time. Or from a business point of view did they? Intel
current problems are manufacturing and the continuously lower power of their
"legacy" processor (except due to manufacturing problems, this "legacy" is
still mostly the current one) makes it so that people are buying more. Of
course there is AMD back in the game, but the market demand is large enough;
plus AMD would have been there anyway, and, in the fiction that Intel did take
good parts of the perf hit upfront instead of the secu vulns, as competitive
as in the current situation.

The people most annoyed are the users. Intel got away by pretending this was
not really defects in their product but only new SW tricks that they will help
defend against, and their clients just let them say that without much
complaint (well, I guess big ones got some rebate...) but security researchers
and/or processor designers know very well this is bullshit (see the vulns
papers and FAQ) and that they simply fucked-up big time on Meltdown, MDS, etc.
I don't care that a few other vendors did some of the same mistakes: they are
still mistakes and design flaws, and not even something new.

Pretty much the only new shinny thing in this stream of vulns was Spectre and
the few variants that appeared quite early on (but NOT Meltdown&co). The rest
are design flaws that comes from the "oh not a big deal to leak that
potentially privileged data, we will drop anything and trap before any
derivative can go out anyway" mentality. Yeah, no, I'm sorry but the funding
paper about speculation already told to not do that :/ Either they did not do
their homework, or they voluntarily chose to violate the rule.

~~~
simias
>It is known since... forever?, that one should not speculate across security
boundaries.

... if you value security over raw performance. Clearly Intel has decided at
some point that it was worth playing with fire in order to get ahead in
benchmarks. In their defence it seems to have worked reasonably well for them
for quite a while.

>The people most annoyed are the users.

I wish, but I wonder how much of that is true. Are most users even aware of
these problems? They get patched automatically by OS vendors and then most of
the time they won't hear about them anymore. I think the "nobody gets fired
for choosing Intel" will probably still prevail for quite some time.

~~~
rcthompson
I wonder how much of Intel's long-term perceived lead over AMD in performance
is explained by compromising on these security issues that are only in the
past few years being (known to be) exploited.

~~~
blackflame
This might be true in recent history, but Intel's Core architecture had AMD on
its heels for several years.

------
ga-vu
This appears to be one of the four ZombieLoad/RIDL variations, rather than a
new attack: [https://zombieloadattack.com/](https://zombieloadattack.com/)

~~~
avianes
Yes, this is a RIDL variant called "L1D Eviction Sampling". Bolt the RIDL
paper (Addendum 2 B [1]) and the CacheOut paper refer to the CVE-2020-0549:
"L1D Eviction Sampling (L1Des) Leakage".

But the CacheOut paper describes how to use it in practice and why the intel
fix is not sufficient.

[1]:
[https://mdsattacks.com/files/ridl.pdf#page=20](https://mdsattacks.com/files/ridl.pdf#page=20)

------
emn13
I mean, you gotta appeciate their efforts to make something so technical
approachable by the general population, including gems like this in their Q&A:
:-D:

 _What is an operating system?_

 _An operating system (OS) is system software responsible for managing your
computer hardware by abstracting it through a common interface, which can be
used by the software running on top of it. Furthermore, the operating system
decides how this hardware is shared by your software, and as such has access
to all the data stored in your computer 's memory. Thus, it is essential to
isolate the operating system from the other programs running on the machine._

~~~
cptskippy
> An operating system (OS) is system software responsible for managing your
> computer hardware by abstracting it through a common interface

So uh... that's a reference to the IME right? Not the user's installed OS.

~~~
chmod775
No they're speaking of the (user installed) OS.

~~~
cptskippy
I was kind of joking and it's also not explicitly stated, that's just the
assumption the reader makes.

------
loeg
Tl;dr: Another Intel TSX async abort side channel.

See also Intel's advisory: [https://software.intel.com/security-software-
guidance/softwa...](https://software.intel.com/security-software-
guidance/software-guidance/l1d-eviction-sampling) (cite 23 in the CacheOut
PDF).

------
dmix
As someone unfamiliar with creating scientific papers I'm curious if anyone
knows what format the citation modal is using?

[https://imgur.com/a/bem4e8u](https://imgur.com/a/bem4e8u)

Is it for TeX or a common syntax for some publishing platforms to pick up?

~~~
detaro
Bibtex. Originally for the bibtex tool (which generates bibliographies for
(La)TeX documents), but now common with other citation tools too.

------
tuananh
it's like all the security researchers are cheering for AMD

------
Flockster
Is this coordinated with OS providers? It only mentioned that Intel released
microcode.

------
eganist
Dumb question: authors mention this not being exploitable via JS, but what
about WASM?

~~~
johncolanduoni
No, WASM doesn’t expose the ability to generate TSX instructions so it can’t
be used to exploit this.

------
annoyingnoob
Is disabling Hyper-threading a viable work-around in this case?

~~~
sjnu
"CacheOut is effective even in the non HyperThreaded scenario, where the
victim always runs sequentially to the attacker."

------
lukestateson
Intel got cash in, but we've got cacheout.

------
rurban
I've pointed this problem out early last year to libsodium, but they chose to
ignore it.

My memset_s does a full memory barrier, but no others do. Esp. the so-called
"secure" libs.

~~~
shakna
> I've pointed this problem out early last year to libsodium, but they chose
> to ignore it.

I'm guessing you're referencing this [0]. libsodium's response that your
suggestion wasn't enough seems reasonable, as does their response:

> `sodium_memzero` should be considered as best-effort, with reasonable
> tradeoffs.

The documentation for memzero [1] doesn't read like it works 100% of the time,
no matter what. It reads like there are tradeoffs involved.

> My memset_s does a full memory barrier, but no others do. Esp. the so-called
> "secure" libs.

Your memset_s also doesn't work on big endian, whilst "the so-called 'secure'
libs" often do.

I'm fine with self-promotion, but don't disparage efforts that have a much
larger surface that they deal with, simply because you disagree with the
tradeoff they find acceptable. A one-liner isn't enough for that conversation.

[0]
[https://github.com/jedisct1/libsodium/issues/802](https://github.com/jedisct1/libsodium/issues/802)

[1]
[https://download.libsodium.org/doc/memory_management#zeroing...](https://download.libsodium.org/doc/memory_management#zeroing-
memory)

~~~
rurban
The tradeoff they are talking about is leaving secrets in the cache, because
mb(lb) is slow. This is not acceptable for security, only for performance.
That time they had no idea about the upcoming cache exploits, they were only
apparent to me. So who was right?

~~~
shakna
> That time they had no idea about the upcoming cache exploits, they were only
> apparent to me. So who was right?

I don't see anything that suggests you did have an idea about "upcoming cache
exploits", so I'm afraid I can't say that you were.

I saw you mentioning something that would help, but was nowhere near enough,
to deal with Spectre, which was then dealt with by microcode, kernels and
every other part of the software stack, making attacking libsodium with
Spectre something that might not even be possible.

> The tradeoff they are talking about is leaving secrets in the cache, because
> mb(lb) is slow. This is not acceptable for security, only for performance.

Not entirely. The main reason is this one:

> SPECTRE-like attacks can be conducted during all the time the secret is
> present, prior to zeroing. The required preconditions and the time window
> during which a full memory barrier could help, seem to be negligible
> compared to the actual lifetime of the secret.

------
baybal2
Again, I reiterate: it's not humanly possible to make performant, general
purpose CPU that is 100% safe from instruction level attacks.

Untrusted code execution must go, that's the only way.

The genie is out of the bottle now. There will be more and more practical
instruction level attacks with each year now.

~~~
heavyset_go
> _Untrusted code execution must go, that 's the only way._

This is how you get corporate rule over what can and can't run on machines you
own.

 _Safer_ architectures can be developed, without handing over control to a
third party.

~~~
baybal2
I don't believe that even a complete comparch-101 in-order, non-pipelined,
architecture without branch prediction, and register renaming can be made safe
enough.

But yes, the industry made an extremely risky bet a decade ago with both
virtualisation, and running unsafe Javascript with JIT.

It will take many billions for the industry to do a U-turn, and switch back to
dedicated servers as a golden standard, and putting a leash on ambitions of
browser makers.

~~~
cpudestw2020
> I don't believe that even a complete comparch-101 in-order, non-pipelined,
> architecture without branch prediction, and register renaming can be made
> safe enough.

Disagree. You do have to put a lot of work into the process. Formal spec as
well as a formal method/simulation. There are certainly a lot of fun things to
consider in that, but I don't think it's completely unfeasible.

As an aside, one of the things that intrigues me about RISC-V is things such
as a formal instruction set spec being openly published [1]. You could apply
all sorts of tooling to that before actually creating silicon.

> But yes, the industry made an extremely risky bet a decade ago with both
> virtualisation, and running unsafe Javascript with JIT.

Focusing so much on Jitting JS was as bad idea then just like it was now. The
entire world of the web is artificially propped up and will probably die the
way it should have died when it started: with people frustrated by constant
security vulnerabilities enabled by a group of ad companies who don't care
about anything but money.

> It will take many billions for the industry to do a U-turn, and switch back
> to dedicated servers as a golden standard, and putting a leash on ambitions
> of browser makers.

WRT Dedicated servers, if anything the industry needs that push now anyway.
I've yet to see a 'Real' cost projection on a SaaS 'rewrite'; i.e. if the
current thing has been in use 5 years longer than it should have, your cost
models should go out 5 years longer than you intend your new solution to
exist.

Which would be ironic; my pain is in the beancounting side (usually what an
org really cares about) yet security will be the more likely scenario.

I think the cat is out of the bag for the browser market though. Users have on
the whole gotten 're-enclosed' thanks to modern laptops tending towards small
eMMC or SSD sizes.

But FFS, this sort of thing is the reason WASM scares the daylights out of me.

[1] [https://github.com/mrLSD/riscv-fs](https://github.com/mrLSD/riscv-fs)

~~~
cpudestw2020
Can't edit, but obviously the web won't die. But it is going to change a bit
over the next few years still; the privacy changes are likely to be a big
catalyst for a lot of change...

~~~
BlueTemplar
Any idea if the fundamental incompatibility between GDPR and "cloud" is ever
going to come home to roost? (You know, how personal data is supposed to be
deleted on request, but the whole idea of "deletion" is pretty hard to
properly execute in practice without physically destroying the storage,
especially for transistor-based storage like SSDs!)

~~~
catalogia
Is simply unlinking a file in the FS not sufficient for GDPR compliance?

~~~
wizzwizz4
It's supposed to be erased, not put in a pile of “things to write over at a
later date”.

