231–240 of 639 posts
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.
"Before the issues described here were publicly disclosed, Daniel Gruss, Moritz Lipp, Yuval Yarom, Paul Kocher, Daniel Genkin, Michael Schwarz, Mike Hamburg, Stefan Mangard, Thomas Prescher and Werner Haas also reported them; their [writeups/blogposts/paper drafts] are at" Does anyone have any color/details on how this came to be? A major fundamental flaw exists that affects all chips for ~10 years, and multiple inde…
https://cyber.wtf/2017/07/28/negative-result-reading-kernel-... Failed attempt in July which is being attributed as earliest work via https://twitter.com/lavados/status/948700783259811847
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 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 ). 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?
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/
Earlier quoted context omitted.
Sounds like maybe SOME ARM and SOME AMD are implicated, especially since the Android ARM CPUs appear to be fine...
There aren't really any special Android ARM CPUs, maybe they are confident it doesn't really work on Android because it's very difficult to get the timing precision and low-level assembly sequences in Java/ART compiled code. Though I wonder how that squares up with JNI. I think the key to the statement is in any case that you need to differentiate between what is possible on the processor architecture level when you…
Earlier quoted context omitted.
You can't unwind completely. Once the cache is full, to load something on the cache, it has to evict something else. You might be able to evict what you just loaded, but you can't undo the earlier eviction.
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.
May be one way would be to use a smaller, separate cache for speculative execution and then copy that value to the regular cache once speculation is confirmed? This would add a one cycle latency for cache-to-cache transfer but there might be better ways.
Someone correct me if I understood this wrong. The way they are exploiting speculative execution is to load values from memory regions which they don't have permission to a cache line, and when the speculation is found to be false, the processor does not undo the write to the cache line? The question is, how is the speculative write going to the cache in the first place? Only retired instructions should be able to mo…
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.
> Mitigation is to insert mfence instructions throughout jit generated sandboxed code making it very slow, ugh. Here's the synchronized announcement from Chrome/Chromium: https://sites.google.com/a/chromium.org/dev/Home/chromium-se... "Chrome's JavaScript engine, V8, will include mitigations starting with Chrome 64, which will be released on or around January 23rd 2018. Future Chrome releases will include additional…
I wonder what this sentence in the Google product status page ( https://support.google.com/faqs/answer/7622138 ) means, particularly what the inter-guest attack refers to: "Compute Engine customers must update their virtual machine operating systems and applications so that their virtual machines are protected from intra-guest attacks and inter-guest attacks that exploit application-level vulnerabilities"
Earlier quoted context omitted.
I 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 ). 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?
> 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…
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...