12 ms·
Papers describing each attack: https://meltdownattack.com/meltdown.pdf https://meltdownattack.com/meltdown.pdf https://spectreattack.com/spectre.pdf https://s
by jotux 9y ago
Papers describing each attack:
https://meltdownattack.com/meltdown.pdf https://meltdownattack.com/meltdown.pdf
https://spectreattack.com/spectre.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.
- pogba101 9y agoThanks for the links. As an undergrad with limited knowledge of this subject, I would love to see these annotated on Fermat's Library (https://fermatslibrary.com https://fermatslibrary.com)
- InclinedPlane 9y agoThis is so incredibly bad. Spectre is basically unpatchable. We can do better than we are now with patches but it's all just turd polishing, essentially. A proper fix will require new CPU hardware. And as a kicker? Leaks are basically undetectable.
- deleted 9y ago[deleted]
- deleted 9y ago[deleted]
- bonzini 9y agoNew CPU microcode is enough, though at a performance price. On pre-Zen AMD there is also a chicken bit to disable indirect branch prediction. (It feels good to be finally able to speak about this freely!!!) I don't know for which processors Intel and AMD plan to release microcode updates.
- contrarian_ 9y ago> New CPU microcode is enough What would that entail? Disabling speculation completely? Disabling memory accesses during speculation?
- bonzini 9y agoDisabling indirect branch prediction (and thus speculation after indirect branches) while in kernel mode, or flushing the indirect branch predictor on kernel mode entry. Both need OS support in addition to the microcode, but the change is less invasive than PTI.
- contrarian_ 9y agoThat only fixes one variant of Spectre, and only for code running in kernel mode. The "out of bounds" Spectre variant is still feasible. Also: What about hyperthreads? It seems to be many people's assumption that the BTB is shared within a physical core.
- bonzini 9y agoThe out of bounds variant is fixable in the OS, just add a fence instruction between the check and the load. For code running in user mode, you flush the branch predictor on each context switch---again, new microcode + patched OS. Hyperthreads are tricky. Those are not yet fixed by microcode AIUI, and in the future you may want a usermode program to say "I don't want indirect branch prediction because I am afraid of what the other hyperthread might do to me". That would require some new system call (like a new prctl on Linux) or something like that.
- wilun 9y agoGreat. Now we just have to think of new attacks using the same general idea to slow down all computers by yet another 10% :p
- PeterisP 9y agoWouldn't that be a serious performance hit?
- minxomat 9y agoGetting flashbacks of brainsmoke's JS PoC: https://youtu.be/ewe3-mUku94?t=1766 https://youtu.be/ewe3-mUku94?t=1766 Edit: Also, PoCs for unpatched Windows by pwnallthethings: https://github.com/turbo/KPTI-PoC-Collection https://github.com/turbo/KPTI-PoC-Collection
- waz0wski 9y agorightfully so: https://twitter.com/brainsmoke/status/948561799875502080 https://twitter.com/brainsmoke/status/948561799875502080
- FLUX-YOU 9y agoI do also wonder if some speculative prediction / branching stuff can be controlled through undocumented CPU instructions: https://www.youtube.com/watch?v=KrksBdWcZgQ https://www.youtube.com/watch?v=KrksBdWcZgQ
- jhallenworld 9y ago"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.
- simion314 9y agoFrom the article it seems that is not 100% sure AMD and ARM are not affected by metldown, only that they could not trigger the issue, but authors mention this "However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indicating that out-of-order execution generally occurs and instructions past illegal memory accesses are also performed."
- jhallenworld 9y agoI would think that any sane implementation would not transmit privileged data to waiting instructions. Look at their Listing 2: Instructions 5 - 7 will be waiting for the privileged data from line 4 (they are not speculatively executed since they have a data dependency on line 4). So why is Intel releasing the privileged data to the waiting instructions? An answer could be that violation checking is delayed until retire, but other implementations are possible. Anyway, so it could be that AMD and ARM are vulnerable, but it's possible that they are not.
- olliej 9y agoThere are two different issues. 1. Intel only (so far) is related to prefetching privileged memory 2. More or less everyone: Speculatively executing code that has variable execution time.
- bonzini 9y ago> I would think that any sane implementation would not transmit privileged data to waiting instructions. The point of VIPT caches is exactly to use data before all the checks are completed. It's easy to judge the sanity of things ex post, but maybe it's not that easy if it took 20 years to find the issue.
- theptip 9y agoI think this means we should consider all browser processes to be completely insecure, until mitigations are applied (e.g. Chrome's Site Isolation: https://www.chromium.org/Home/chromium-security/ssca https://www.chromium.org/Home/chromium-security/ssca). Looks like any session token/state could be exfiltrated from your Gmail tab to a malicious JS app running in-process, for example. Am I overreacting here?
- kibwen 9y ago> Am I overreacting here? Still skimming the paper, but the JS attack appears to be processor-intensive (please chime in if you interpret it differently!). Any widespread, indiscriminate use of such an attack in the wild seems like it would eventually be detected as surely as client-side cryptocurrency mining was discovered. If you aren't a valuable target, if you don't visit sites that are shady enough to discreetly mine bitcoin in your browser, and if you use an adblocker to defang rogue advertisers, then you probably shouldn't lose too much sleep over this (which is not intended to diminish how awesome (in the biblical sense) this attack is). That said, if there were ever a time to consider installing NoScript, now's it: https://addons.mozilla.org/en-US/firefox/addon/noscript/ https://addons.mozilla.org/en-US/firefox/addon/noscript/
- jwilk 9y agoAnd if you're a web developer, now it the good moment to make sure your site works correctly when JS is disabled.
- thisacctforreal 9y agoYes please! Long live progressive enhancement and graceful degradation. At least until we get a JS interpreter with proper permission controls and sandbox limits. Something closer to how Lua is embedded sounds nice.
- deckard1 9y agoWe'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.
- ErikAugust 9y agoI've thrown the C code in the Spectre paper up if anyone wants to feel the magic: https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6 https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9...
- airesQ 9y agoWorked on my system. (Set cache_hit_threshold to the default value of 80, my cpu is an Intel i7-6700k.)
- ojiikun 9y agoThanks for this. Would love an annotated version of this if anyone is up for it. My C is pretty good, but some high level "what is being done here" and "this is what shouldn't work" comments would be cool to see.
- JetSpiegel 9y agoWorked on a Intel(R) Celeron(R) CPU 847 @ 1.10GHz. With "gcc (GCC) 7.2.1 20171128", remove the parenthesis from CACHE_HIT_THRESHOLD macro[1] to compile correctly. [1]: https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6#file-spectre-c-L50 https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9...
- dpwm 9y agoJust 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?
- marzell 9y agoWill it be nontrivial to detect or at least identify these types of exploits as they occur in the wild? Can protection software see these when they happen, assuming a best case scenario where the attack is carried out but doesn't specifically use these methods to hide or disable detection? Is there a general sense yet of whether this exploit is already being leveraged?
- boltzmann_brain 9y agoI've hacked together a simple simulation of meltdown based on the paper. It runs the pipelined instructions after exception has been raised and then snoops the data via cache flush and reload. Windows only for now. The _snoop function is pipelined after exception - this function loads the byte from the specified address and forces a cache load based on the value, which is then recovered via cache flush and reload. If you removed forced exception in the try block and pass in e.g. a possible kernel address, the load itself will trigger an exception and the bytes from that address can be recovered. I haven't been able to find a kernel address that works - I guess kernel address space separation fix makes it very difficult. https://github.com/bsekura/meltdown https://github.com/bsekura/meltdown
- rsync 9y ago"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" I am not sure what "the process in which it runs" means here ... do they mean private memory from within chrome ? Or within the child process spawned from chrome, or within the spawned JS sandbox or ... what ? Practically speaking, I worry about a browser pageview that can read memory from my terminal process. Or from my 'screen' or 'sshd' process. I think that is not a risk here, yes ?
- guftagu 9y agoGuys, can't we just detect a program doing spectre-like behavior and just kill it instead of having every other application suffer a performance hit by the proposed changes? Antivirus software already does similar stuff