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

21–30 of 137 posts

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

#21

Post by jandrese »

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

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

#22

Post by Tuna-Fish »

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…

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

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

#23

Post by FisDugthop »

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…

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.

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

#24

Post by jdsully »

loeg wrote: post #18
jdsully wrote: post #15

Earlier quoted context omitted.

Only the implicit TSX has been disabled. You can still use xbegin/xend/xabort. They had an additional mode that would transparently convert many spinlocks into transactions without code changes - that is now gone.

"Should" as in, I think the earlier vulnerability was damning enough that people /should/ have disabled TSX entirely. If they have not already, they /should/ now.

TSX can provide very important speedups where there aren't adversarial workloads sharing memory. Your web browser shouldn't be using it, but I think turning it off globally doesn't make much sense. Unlike hyperthreading use of TSX can be decided on an app to app basis.

As core counts increase spinlocks and other synchronization primitives simply become too expensive. We'll need transactional hardware support eventually.

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

#26

Post by detaro »

dmix wrote: post #25

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 Is it for TeX or a common syntax for some publishing platforms to pick up?

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

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

#27

Post by scandinavian »

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

>but the instant it's in a rootkit everybody will be able to do it.

This makes no sense. If you have the privileges to install a rootkit, there is no need to use any speculative execution exploit.

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

#28

Post by wwwhizz »

dmix wrote: post #25

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 Is it for TeX or a common syntax for some publishing platforms to pick up?

That's bibtex, for LaTeX.

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

#29

Post by jandrese »

scandinavian wrote: post #27
jandrese wrote: post #21

Earlier quoted context omitted.

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

>but the instant it's in a rootkit everybody will be able to do it. This makes no sense. If you have the privileges to install a rootkit, there is no need to use any speculative execution exploit.

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

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

#30

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

Post reply on HN