I'm afraid that jnordwick doesn't consider PoCs to be "real" enough for some reason. [0] I think he's waiting for a piece of malware to be found in the wild before he'll consider it a problem.
Just something that would work in the wild. There are a number of things that might theoretically be possible if the machine of complicit with you but aren't actually exploitable.
Like i said:
- JavaScript appears to not be a possible attack vector. So now we're just worried about already had access to run a native binary.
- so a native program that sat snooping sudo passwords would be a good demo, but obviously if a rogue binary had to sit running for days with only a part success rate, we would be able to attack stupid managers and evil corporations because it wouldn't be very impressive. If I'm already running binary code, i have a lot of better ways to attack the system.
> JavaScript appears to not be a possible attack vector. So now we're just worried about already had access to run a native binary.
All the major browsers have pushed patches, to close this, because it was a gaping hole. You're only not worried, because they've already fixed it. (Well, when I say major browsers, I haven't seen or heard anything from Microsoft's Chakra engine.)
Take note that it involved killing off SharedArrayBuffer in JS, at least for now.
> but obviously if a rogue binary had to sit running for days with only a part success rate
That's misreading the situation.
A tight loop is required, yes, with partial failure, but it is not so low as taking days. The original implementation [0], read at around 10KB/s. Whilst that isn't fast if you're somehow trying to read gigabytes of data into cache, and then attack it, it's more than enough to read passwords out of data.
> So now we're just worried about already had access to run a native binary.
Now we're worried about any unpatched JavaScript engine, like perhaps Chakra, which would make all Edge users vulnerable.
You also don't need access to an executable binary. You could also target any DLL that gets dynamically linked on Windows. In fact, the example Windows implementation hooks into ntdll.dll, which has a known location on all versions of Windows, which allows it to bypass ASLR.
I'm not sure I understand his position on Spectre, but he's been pretty clear that for the most part he's been talking about Meltdown. Honestly I'm not familiar with how much of a perf hit the Meltdown patch alone causes, because I always see the bad perf numbers with their combination, but I suspect it's bad. Since Meltdown has no JS exploit, there's no reason to worry about JS. Given that browser exploits are out of the question, the threat reduces to the normal threat of running untrusted code. I see no reason to worry more about Meltdown specifically than I have to worry about any application I run sneakily running `xinput test-xi2 --root`, so given the choice, I'm not going to apply the Meltdown patches on my desktop machine and suffer a perf hit for no good reason. Spectre patches, maybe, but I might not if the browser situation is confidently dealt with.
I think it would be useful to write up a technical article on the cache side channel attack and how it is used by meltdown and specte and their different methods of exploit.
Maybe that would shed some light on who needs to worry and why.
I'm surprised the js jit writers have escaped with so little blame for Spectre since in the end it is basically just a process reading its own address space (I'm actually surprised more of these vulnerabilities don't exist since things like proc/dev/run are ripe for abuse).
