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

Re: Reading privileged memory with a side-channel

#331

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

dmm wrote: post #284

deckard1 wrote: post #276

Earlier quoted context omitted.

We'll have to dig a time machine out and go back to 1998 then. I'm being a facetious ass. But you know I'm not wrong, either.

You are wrong. Install the NoScript extension and you can see your site without js. NoScript also allows you to selectively enable js per site on a temporary or permanent basis. This is the default way that I and many other people browse the web. https://noscript.net/

As a developer, it's even easier to test without Javascript: open Chrome Developer Tools, select Settings from the hamburger menu, and check "Disable Javascript".

As the other comments point out, though, the biggest problem is that this is economically irrational for most site owners. The figures on JS-disabled usage I had when I was still at Google (3+ years ago now) were at the lower end of TikiTDO's range. It generally doesn't make economic sense to spend developer time on an experience used by 0.1% of users, particularly if this requires compromises for the 99.9% of users who do have JS enabled.

Re: Reading privileged memory with a side-channel

#332

Post by olliej » Thu, Jan 04, 2018, 2:07 AM UTC

aidenn0 wrote: post #289

dannyw wrote: post #237

Earlier quoted context omitted.

The mitigations are to disable SharedArrayBuffer and severely round performance.now(). Not good that there aren’t other less intrusive ways to mitigate.

That can't be right because they already round performance.now() so the Spectre attack didn't use it (it instead used a webworker with a tight-loop incrementing a counter)

the tight loop iteration used a shared array buffer to provide a high resolution timer, specifically to deal with the obvious fix of truncating precision of performance.now().

The reason for /further/ truncating performance.now() is that the relative cost in this attack means that you don't need as much precision as was needed for the original (page table? I think) attack.

A SAB timer just needs to increment a counter in one thread and read it in the host thread and the granularity is however long it takes to get through a for-loop.

Re: Reading privileged memory with a side-channel

#333

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

MBCook wrote: post #8

chrisb wrote: post #2

"These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running them." Curious. All other reports I've read state that AMD CPUs are not vulnerable.

See the Twitter thread here: https://twitter.com/nicoleperlroth/status/948678006859591682 (Edit: there are 9 posts total, go to her user page to see them all) Seems there are two issues. One, called Meltdown, only effects Intel and is REALLY bad, but the kernel page table changes everyone is making fixes it. The other, dubbed Spectre, is apparently common to the way all processors handle speculative execution and is…

I can't really see how it would be fixable even with new hardware.

Speculative execution is fundamental to getting decent performance out of a CPU. Without it you should probably divide your performance expectations by 5 at least.

Rolling back all state rather than just user visible state in the CPU is neigh on impossible. When you evict something from the cache, you delete it. Undeleting is hard. There are also a lot of other non-user-visible bits of state in a CPU.

Re: Reading privileged memory with a side-channel

#334

Post by olliej » Thu, Jan 04, 2018, 2:09 AM UTC

AsyncAwait wrote: post #28

partiallypro wrote: post #16

So, is AMD effected or not? This seems fairly important. The Google blog post sort of goes against itself in this regard. AMD itself has said: "The threat and the response to the three variants differ by microprocessor company, and AMD is not susceptible to all three variants. Due to differences in AMD's architecture, we believe there is a near zero risk to AMD processors at this time." So either AMD is lying or Goog…

It seems like it is not affected by the most serious bug, but may be by a lesser one.

it is effected by spectre, but not by the other.

Re: Reading privileged memory with a side-channel

#335

Post by caf » Thu, Jan 04, 2018, 2:12 AM UTC

cthalupa wrote: post #316

wahern wrote: post #249

Earlier quoted context omitted.

Then surely you must also argue that all data-dependent, side-channel attacks, such as key recovery attacks against some cryptographic algorithm implementations, are the fault of the hardware. Unlike Intel, ARM and AMD are implicated only where the attacker can inject code or data (specifically data that is manipulated by pre-existing vulnerable code) into the target address space. The particular kernel exploits requ…

>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 an interpreter or JIT engine that can be used to generate the vulnerable code pattern. So far, we have not actually identified any existing, exploitable instances of the vulnerable code pattern; the PoC for leaking kernel memory using variant 1 uses the eBPF interpreter or the eBPF JIT engine, which are built into the kernel and accessible to normal users.

For Variant 1, the "vulnerable code pattern" they're looking for has to be of a very specific type, it's not a run-of-the-mill gadget. It has to load from an array with a user-controlled offset, then mask out a small number of bits from the result and use that as an offset to load from another array, where we can then time our accesses to that second array.

However, they also go on to say:

A minor variant of this could be to instead use an out-of-bounds read to a function pointer to gain control of execution in the mis-speculated path. We did not investigate this variant further.

Which seems much less reassuring.

Re: Reading privileged memory with a side-channel

#336

Post by Pyxl101 » Thu, Jan 04, 2018, 2:13 AM UTC

tankenmate wrote: post #177

comex wrote: post #50

Earlier quoted context omitted.

Not just user memory reads. AMD CPUs won’t speculate loads from userland code directly to kernel memory, ignoring privilege checks (“Meltdown”). But they are still subject to the “Spectre” attack, which can disclose kernel memory by taking advantage of certain code patterns (which normally would be harmless) in kernel code.

But that means the root user or someone with root effective privs or CAP_* to load programs into a kernel interpreter or kernel JIT. If you've given someone permission to do this from a user process you've probably opened up to more mundane issues. I suspect this is why AMD says the issue is near zero, if you've given away the keys to the kernel you're already in trouble. AMD's ASID blocks the issues for VM guests (a…

Do you need root or comparable privileges to take advantage of BPF? I did not think that was the case. My understanding was that BPF code executes within the kernel.

BPF is employed by the `bpf()` syscall for socket packet filtering, as well as by `seccomp` itself for its syscall filtering. Is this threat vector not available to untrusted processes?

Re: Reading privileged memory with a side-channel

#337

Post by comex » Thu, Jan 04, 2018, 2:14 AM UTC

tankenmate wrote: post #261

tankenmate wrote: post #215

Earlier quoted context omitted.

I'm not sure I see how to use the Spectre attack on AMD without running in kernel context. What am I missing?

I should clarify I mean user to root privilege escalation. I totally understand how the breaking out of the javascript sandbox attack works and the fact that IPT won't help with that. With Linux's clone(), you could clone without CLONE_VM and use CLONE_NEWUSER|SYSVMSEM and then unmap everything except the Javascript interpreter / JIT and leave a shared memory map and communicate only via the shared memory map and SYS…

By "user to root privilege escalation", I'll assume you mean leaking kernel data without root, since this attack doesn't directly allow escalating privileges at all.

For variant 1, you would need to find some legitimate kernel code, accessible by syscall, that looks at least somewhat similar to the example in the Project Zero blog post:

    if (untrusted_offset_from_caller length) {
        unsigned char value = arr1->data[untrusted_offset_from_caller];
        unsigned long index2 = ((value&1)*0x100)+0x200;
        if (index2 length) {
            unsigned char value2 = arr2->data[index2];
        }
    }

In practice, you may not be able to find something nice like "((value&1)*0x100)+0x200", but even if it simply used 'value' as an index, you would be able to at least narrow it down to a range. Other code patterns may work too (and potentially be more powerful?), e.g. conditional branches based on 'value'.

For variant 2, see caf's answer to you in another thread.

Re: Reading privileged memory with a side-channel

#338

Post by martinald » Thu, Jan 04, 2018, 2:14 AM UTC

noncoml wrote: post #225

Cyph0n wrote: post #120

Earlier quoted context omitted.

Yes, from my understanding, Spectre is an architectural-level flaw in the so-called speculative execution unit. In other words, Spectre will only be fixed once Intel, AMD, and ARM redesign the unit and release new processors. Given the timelines of CPU design, this will take 5-10 years at least. On the positive side, the flaw is very difficult to exploit in a practical setting.

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

Re: Reading privileged memory with a side-channel

#339

Post by labster » Thu, Jan 04, 2018, 2:16 AM UTC

Certhas wrote: post #207

jhallenworld wrote: post #187

Earlier quoted context omitted.

"Meltdown" is an Intel bug. "Spectre" is very bad news and affects all modern CPUs. Mitigation is to insert mfence instructions throughout jit generated sandboxed code making it very slow, ugh. Otherwise assume that the entire process with jit generated code is open to reading by that code. Any system which keeps data from multiple customers (or whatever) in the same process is going to be highly vulnerable.

After skimming the articles it sounds like a lot hinges on just how hard Spectre is to pull off in practice/in the wild. Anyone have any insights on that?

I don't know much about this particular flaw, but I imagine it'll be pretty hard until someone releases an exploit kit, and then pretty easy after that.

Re: Reading privileged memory with a side-channel

#340

Post by cmurf » Thu, Jan 04, 2018, 2:16 AM UTC

There are 3 known CVEs related to this issue in combination with Intel, AMD, and ARM architectures. Additional exploits for other architectures are also known to exist. These include IBM System Z, POWER8 (Big Endian and Little Endian), and POWER9 (Little Endian).

https://access.redhat.com/security/vulnerabilities/speculati...