6 ms·

I understand this "isn't the point" etc - for curiosity sake: How practical are these exploits? From my reading, it seems using them in an attack against a soph

• NoGravitas 9y ago
  It looked like one of the proofs of concept was using javascript code to escape the sandbox and read memory from the browser's address space. So that seems to be quite a realistic attack vector, right?
• ashleyn 9y ago
  Depends on the browser. Chrome has mitigations, but not solutions to this, which largely consist of degrading the quality of the timer required to pull off Spectre. WebWorkers give you a more accurate timing method that can pull it off. Basically, any website can now theoretically read your encryption key in RAM and something like noscript will be required, not optional for maximum safety.
• pjc50 9y ago
  A nice little gif from twitter: https://twitter.com/misc0110/status/948706387491786752 https://twitter.com/misc0110/status/948706387491786752 User typing into a "secure" Linux (edit: was MacOS - can we do strikethrough here?) password dialog while another process steals the data. The first attack was incredibly difficult, but once there's a proof of concept, copies will proliferate.
  • fzzzy 9y ago
    That looks like linux, not mac os. But still.
  • arianvanp 9y ago
    That's Gnome, not MacOS ;)
  • williamstein 9y ago
    That demo is Linux, not MacOS: "Full Ubuntu was running with Firefox in the background. [...] it is only a demo app (a simple GTK application on Linux)."
• pwg 9y ago
  Based on the description here: https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html https://googleprojectzero.blogspot.com/2018/01/reading-privi... These attacks are very practical. Unprivileged code, doing nothing inherently wrong (so very hard to detect), reading arbitrary memory locations contents at a rate of about 2000 bytes per second. Another blog somewhere (I no longer have the URL) indicated that the Google group that helped discover the issue also managed to read arbitrary, normally inaccessible, memory locations from Chrome by running JavaScript. Which makes the attack feasible remotely using nothing but a properly programmed malicious website.
  • MrBuddyCasino 9y ago
    In all fairness, they disabled SharedArrayBuffer and diluted clock precision, so afaik the JS attack vector can be eliminated for patched browsers (FF did the same).
    • kodablah 9y ago
      I don't think this is enough. I think this just mitigates the ability to use high precision to determine cache misses on array accesses. The leaked data is still there and the paper says it's one of 64 possibilities. Enabling site isolation helps since it's only process memory. Someone correct me if I misunderstand. EDIT: Also, just confirmed via https://jsfiddle.net/5n6poqjd/ https://jsfiddle.net/5n6poqjd/ that only FF has SharedArrayBuffer disabled. Chrome isn't going to release 64 which has SharedArrayBuffer disabled for a couple of weeks.
    • bzbarsky 9y ago
      The SAB and clock changes are all to reduce timer precision. Reducing timer precision doesn't _fix_ the problem, but does reduce the rate of the data leak, which means it takes longer to exfiltrate the same information. Whether this is sufficiennt mitigation depends on your threat model and the exact amount of rate reduction. For example, a leak of 1 byte per hour might be OK in some threat models but not others.
      • 9y ago
• kodablah 9y ago
  What you need are some use cases. Imagine going to a website that had some JS that could read memory of that browser process. I'm not sure what's in Chrome's memory and the process is shared (without site isolation enabled) by iframes and referring pages and what not IIRC. But basically, imagine you could go to a certain website and they could open bankofamerica.com in a hidden frame and if you were logged in, they could possibly find spots in memory that had that site's information. Or Google, or Facebook, or whatever. Could be worse depending upon how Chrome's password manager stores passwords in memory.
  • deleted 9y ago
    [deleted]
• kllrnohj 9y ago
  Meltdown (which so far is proven to impact Intel whereas AMD's design appears to negate it pretty much entirely) is catastrophically practical to use. Meltdown can read kernel memory at a rate of around 503 KB/s according to the paper. Not enough for a RAM dump probably, but if you can generally figure out what you want and where to look you've got plenty of bandwidth to dump it. All you need is code execution at any privilege level and an Intel host without the kernel workaround (so that's, what, ~95% of servers/desktops in the world currently?). Spectre appears far less significant in practice. The primary exploit target seems to be via JavaScript to snoop on the hosting browser process (aka, running untrusted code in your own process just became borderline impossible). If you're in your own process, though, being able to read other processes memory appears non-trivial. There wasn't any example of actually doing this in the paper, but it was speculated to be possible. The example code has the attacking code and the victim code in the same process (aka, you could also just get the secret by just reading it - the "attacker" had full read access to the memory to begin with). It was speculated that this could be done via IPC to get another process to inadvertently leak, but there was no PoC of this and given how much overhead (in terms of CPU time/instructions) there is in all forms of IPC I'm not sure how realistic that actually is in practice.
  • neom 9y ago
    Thank you for this very detailed reply. Re: Meltdown - It would still take quite some effort to craft a series of events that would result in significant access to say, a banking or government system (the crux being the code execution)?
    • kllrnohj 9y ago
      If your bank or govt system uses AWS or any other cloud shared hosting provider it's probably quite possible to get code on the same physical machine.