Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CacheOut: Leaking Data on Intel CPUs via Cache Evictions

cacheoutattack.com

Post reply on HN
Print view View original

71–80 of 137 posts

Re: CacheOut: Leaking Data on Intel CPUs via Cache Evictions

#71

Post by all_blue_chucks »

vojta_letal wrote: post #64
all_blue_chucks wrote: post #61

Earlier quoted context omitted.

These CPU vulns have all been related to performance optimizations. Do you have any reason behind your claim that a CPU without such optimizations would be vulnerable?

It's harder to believe that there is _no way to leak information_ than the opposite. There is always a side channel, right? Timing is the most trivial one.

When every instruction takes the same amount of time (no speculative execution or cache sharing), then no, there is no timing attack. There isn't any reason to support the claim that all CPUs are fundamentally vulnerable to these types of attacks.

Re: CacheOut: Leaking Data on Intel CPUs via Cache Evictions

#72

Post by rcthompson »

simias wrote: post #31
temac wrote: post #20

Earlier quoted context omitted.

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…

>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 tru…

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.

Re: CacheOut: Leaking Data on Intel CPUs via Cache Evictions

#73

Post by GranPC »

strstr wrote: post #63
jnordwick wrote: post #19

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 no…

How do you disable TSX? I don't see a control register flag or an MSR.

MSR IA32_TSX_CTRL, introduced with a microcode update a while back.

Re: CacheOut: Leaking Data on Intel CPUs via Cache Evictions

#74

Post by foota »

scandinavian wrote: post #33
jandrese wrote: post #29

Earlier quoted context omitted.

The first feature of a rootkit is to get root access. A userspace kernel-information leak utility would be very useful for this step.

Okay, we have differing definitions of what a rootkit is it seems.

They mean in the implementation of a rootkit.

Re: CacheOut: Leaking Data on Intel CPUs via Cache Evictions

#75

Post by strstr »

GranPC wrote: post #73
strstr wrote: post #63

Earlier quoted context omitted.

How do you disable TSX? I don't see a control register flag or an MSR.

MSR IA32_TSX_CTRL, introduced with a microcode update a while back.

Wow, it's not even in the SDM. Only docs I can find are: https://software.intel.com/security-software-guidance/insigh...

Glad it's possible to do this in virt now: used to be impossible to disable TSX (you could avoid advertising it via cpuid, but you couldn't actually prevent usage of the instructions).

Re: CacheOut: Leaking Data on Intel CPUs via Cache Evictions

#76

Post by guug »

jnordwick wrote: post #19

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 no…

The "nutty"ness comes from people getting frustrated with intel fucking up the security of yet another feature they promised, and intel's overall poor security record.

Luckily there are other vendors who seem to know what they're doing: We just received our first batch of non-intel servers at work and have no intention of returning to intel for the foreseeable future. What they offer is simply not worth the risk. I expect more companies to follow suit.

Re: CacheOut: Leaking Data on Intel CPUs via Cache Evictions

#77

Post by sitkack »

jnordwick wrote: post #50
FisDugthop wrote: post #23

Earlier quoted context omitted.

By your own numbers, this could translate to a 30-second AES key exfiltration in the cloud. This isn't a non-issue, even if you personally aren't affected.

you have to find the address first, which is a lot of rummaging around. you aren't just handed it. that is going to quite a bit, especially the program build any security measures in (eg, allocate at a random address). good luck with that.

Spread the key over a whole page with fec, implement the key recovery using non saved registers. Would be nice to avoid pre-emption and avoid leaking regs to ram. Perhaps last step could use avx to run a permutation.

Re: CacheOut: Leaking Data on Intel CPUs via Cache Evictions

#78

Post by BlueTemplar »

cpudestw2020 wrote: post #58
cpudestw2020 wrote: post #56

Earlier quoted context omitted.

> 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 i…

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...

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!)

Re: CacheOut: Leaking Data on Intel CPUs via Cache Evictions

#79

Post by sitkack »

cesarb wrote: post #36
Tuna-Fish wrote: post #22

Earlier quoted context omitted.

> 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) 2^12 = 4096, or the x86 page size in bytes.

And as for why the page size is relevant for the L1 cache: Intel (and AMD, and most other modern CPUs) use a VIPT (Virtual Indexed Physical Tagged) L1 cache, where the virtual address (before the page table translation) is used to index the cache (this is faster since it can be done in parallel with the TLB lookup to get the physical address). To prevent the confusing situation where the same physical address has mor…

Does this mean we could see 16x larger L1?

Re: CacheOut: Leaking Data on Intel CPUs via Cache Evictions

#80

Post by userbinator »

jandrese wrote: post #21
jnordwick wrote: post #19

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 no…

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".

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.
Post reply on HN