Reading privileged memory with a side-channel • Hacker News Board

Re: Reading privileged memory with a side-channel

#341

Post by dpwm » Thu, Jan 04, 2018, 2:17 AM UTC

ErikAugust wrote: post #209

jotux wrote: post #115

Papers describing each attack: https://meltdownattack.com/meltdown.pdf https://spectreattack.com/spectre.pdf From the spectre paper: >As a proof-of-concept, JavaScript code was written that, when run in the Google Chrome browser, allows JavaScript to read private memory from the process in which it runs (cf. Listing 2). Scary stuff.

I've thrown the C code in the Spectre paper up if anyone wants to feel the magic: https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9...

Just tested this on systems of varying age.

Works on processors going back as far as 2007 (the oldest I have access to now is an Athlon 64 X2 6000+), but the example code relies on an instruction that the Atom D510 does not suport.

Because Spectre seems to be an intrinsic problem with out-of-order execution, which is almost as old as the FDIV bug in intel processors, I would be very surprised if the Atom D510 did not turn out to be susceptible using other methods as outlined in the paper.

EDIT: I originally suspected this instruction was CLFLUSH and erroneously claimed the D510 doesn't support sse2. It does support sse2, so it must be that it does not support the RDTSCP instruction used for timing.

EDIT: This gets very interesting. I made some modifications to use a CPUID followed by RDTSC, which now runs without illegal instructions and works everywhere the previous version worked. Except on the D510, this runs but I cannot get the leak to happen despite exploring values of CACHE_HIT_THRESHOLD. Could the Atom D510 really be immune from Spectre?

Re: Reading privileged memory with a side-channel

#342

Post by qaq » Thu, Jan 04, 2018, 2:17 AM UTC

Are extensions like 1password vulnerable do they run in the same process as js from a page?

Re: Reading privileged memory with a side-channel

#343

Post by londons_explore » Thu, Jan 04, 2018, 2:18 AM UTC

jsmthrowaway wrote: post #147

cesarb wrote: post #91

Earlier quoted context omitted.

You know it's a bad one when Project Zero allows more than its usual 90-day deadline...

Then front-runs the negotiated timeline anyway, catching projects like Xen off guard (it seems like)[0]. Will be interested to read the postmortem of the entire process from start to finish, and Xen is promising one from their perspective. I'd be especially interested to understand whether public intel was concrete enough to rush this out the door, because it didn't seem like it was, but I probably missed something.…

I reimplemented variant 3 based solely on clues from twitter posts yesterday.

I am by no means a computer security guru - I just did a CPU architecture course at uni and figured I'd cowboy up an implementation. It worked nearly first time, and can read both kernel and userspace pages from userspace by fooling the branch predictor into going down the wrong path, and relying on the permission checks to be slower than the data reads from a virtually addressed cache. It can only access stuff already cached though, so you can't do a full memory dump with it.

Re: Reading privileged memory with a side-channel

#344

Post by j_coder » Thu, Jan 04, 2018, 2:20 AM UTC

quotemstr wrote: post #304

j_coder wrote: post #198

Isn't possible for the kernel to patch all clflush instructions when the software is loaded to keep a circular list of all evicted addresses that would be evicted again on the interrupt that happens when the protected address is read? This way the the timing attack would not be possible.

clflush only makes the attack easier. There are other ways to flush the cache. Besides: code is mutable. You can just make a clflush instruction out of thin air without the loader's involvement.

For software that requires self-modifying code to run the existing Linux kernel patch would apply (performance penalty). If there is other ways to flush the cache it is necessary to evict the entire software memory on the interrupt.

Re: Reading privileged memory with a side-channel

#345

Post by noncoml » Thu, Jan 04, 2018, 2:21 AM UTC

martinald wrote: post #338

noncoml wrote: post #225

Earlier quoted context omitted.

> On the positive side, the flaw is very difficult to exploit in a practical setting. Is it? "As a proof-of-concept, JavaScript code was written that, when run in the Google Chrome browser, allows JavaScript to read private memory from the process in which it runs"

So is this fixable or not?

Not really.

See: https://blog.mozilla.org/security/2018/01/03/mitigations-lan...

Re: Reading privileged memory with a side-channel

#346

Post by j_coder » Thu, Jan 04, 2018, 2:23 AM UTC

j_coder wrote: post #344

quotemstr wrote: post #304

Earlier quoted context omitted.

clflush only makes the attack easier. There are other ways to flush the cache. Besides: code is mutable. You can just make a clflush instruction out of thin air without the loader's involvement.

For software that requires self-modifying code to run the existing Linux kernel patch would apply (performance penalty). If there is other ways to flush the cache it is necessary to evict the entire software memory on the interrupt.

So in all cases just evict the entire process memory from the cache when the interrupt is raised when reading from a protected memory. The performance penalty would apply only to misbehaved code.

Re: Reading privileged memory with a side-channel

#347

Post by cthalupa » Thu, Jan 04, 2018, 2:26 AM UTC

caf wrote: post #335

cthalupa wrote: post #316

Earlier quoted context omitted.

>The particular kernel exploits require injection of a JIT-compiled eBPF program, as they said they were unable to locate any suitable gadgets in existing compiled kernel code Did they say that? I don't see anything saying they were unable to, just that they didn't bother to because it would take effort. >But piecing gadgets together and figuring out which ones work in a speculation context seems annoying. So instead…

The quote you have is for exploiting Variant 2, the post above yours was talking about Variant 1. For Variant 1, the authors say: To be able to actually use this behavior for an attack, an attacker needs to be able to cause the execution of such a vulnerable code pattern in the targeted context with an out-of-bounds index. For this, the vulnerable code pattern must either be present in existing code, or there must be…

Gotcha! Thanks for setting me straight here.

Re: Reading privileged memory with a side-channel

#348

Post by willsr » Thu, Jan 04, 2018, 2:34 AM UTC

rarudduck wrote: post #317

Azure's response: https://azure.microsoft.com/en-us/blog/securing-azure-custom... This part is interesting considering the performance concerns: "The majority of Azure customers should not see a noticeable performance impact with this update. We’ve worked to optimize the CPU and disk I/O path and are not seeing noticeable performance impact after the fix has been applied. A small set of customers may experience some…

Interesting that they left it this late.

Re: Reading privileged memory with a side-channel

#349

Post by geertj » Thu, Jan 04, 2018, 2:35 AM UTC

What is the reason that Intel would allow speculative instructions to bypass the supervisor bit and access arbitrary memory? That seems the root cause for Meltdown.

Is it that the current privilege level could be different between what it is now, and what it will be when the speculative instruction retires? If so then that seems a thin justification. CPL should not change often so it doesn't seem worth it to allow speculative execution for instructions where a higher CPL is required.

Re: Reading privileged memory with a side-channel

#350

Post by londons_explore » Thu, Jan 04, 2018, 2:36 AM UTC

gmueckl wrote: post #290

static_noise wrote: post #121

Earlier quoted context omitted.

Only if your speculative reads do cause irreversible side-effects on those caches. You could implement them in a way that doesn't modify the caches... but that would be complicated and probably use more power and have lower performance.

There does not need to be a performance hit, but cache complexity must rise: speculative execution must use a separate cache for any data that was fetched speculatively. Only when that branch is truly accepted must that data enter the "real" cache. As long as speculative execution does not go on for too long, these secondary caches can stay really tiny (a handful of cache lines maybe).

The "speculation time" can be hundreds of cycles if you have a branch or memory read that takes a long time to resolve.

This problem is already solved with speculative writes to main memory - a speculative store buffer keeps a sequence of memory operations which need to be done when the operation retires. These buffers are very power hungry, because every future speculative read must check every entry in the speculative store buffer to see if it is re-reading a previously written address. That many to many mapping leads to an exponential amount of checking logic.

The same could be done for cache reads/writes, but I have a feeling it would quickly get very complex, large, and power hungry.