Slashdot Mirror

Unless you can show an exploit that involves a browser visiting a malicious URL in a real-world scenario, I think this is a lot of smoke.

A number of proofs of concept were published that demonstrated how the exploits could be abused using Javascript. For instance, here's a simple example that could be used to provide a script with access to the contents of your memory if your browser/system/chip hasn't been updated to prevent such an attack. This may not impact everyday users much, but if you're on a known, shared system (e.g. AWS, Azure, WordPress, Squarespace, etc.) it becomes far easier to abuse, since you could do something like, say, initiate a request that would load a private key into memory, use a sidechannel attack of these sorts to log the memory out to file, and then suddenly have the keys to the kingdom, which very much so would affect everyday users at that point.

Rowhammer is less directly useful, but it can be used to get a foot in the door. All you need is for the right bits in a page table to flip in just the right way one time to be able to gain complete control of an application with root access. Sure, it's more likely to crash the device than grant you control, but Android users represent a large enough collective target that there'd be plenty of successful exploits accomplished across the user base, and for the remainder of the users it would constitute a major annoyance and frustration as their memory routinely became corrupted, resulting in reboots.

You must improve on your google-fu: https://react-etc.net/entry/ja...

You know this thing called Google exists right? It took me literally 2 seconds to do a search. This was the first result So we're you not just wrong but also so lazy you couldn't spend 2 seconds to do a search?

Multiple exploits are available, aren't they?

https://www.react-etc.net/entry/exploiting-speculative-execution-meltdown-spectre-via-javascript
https://react-etc.net/page/meltdown-spectre-javascript-exploit-example

https://www.react-etc.net/entry/exploiting-speculative-execution-meltdown-spectre-via-javascript
https://react-etc.net/page/meltdown-spectre-javascript-exploit-example

I've tried this exploit code on Win10 with full updates in FF+Chrome+IE, and on LineageOS 14.1-something on FF+Chrome+stock browser. All just give the output "0".

If you've applied the latest patches, then you're already protected. MS released the patch on Wednesday, January 3rd. I see from a quick search that LineageOS is an Android distro. Google announced their patch early this week, though I don't know which Android distros have incorporated it and pushed a new release. Assuming the exploit you linked is legit, you probably want to test it with an unpatched system instead.

I've tried this exploit code on Win10 with full updates in FF+Chrome+IE, and on LineageOS 14.1-something on FF+Chrome+stock browser. All just give the output "0".

how do you get a pointer to kernel memory in JS without needing to break the virtual machine?
var *p = (char *)0xdeadbeef;

Answering the "how to do random memory access in a language without pointers" part of the question: by abusing arrays and boundary checks (link to a Spectre abuse) (Note that it's a Spectre abuse, not a Meltdown abuse. For the meltdown I'll have to track the CCC link).

If a piece of javascript is using the ASM.js specific sub-dialect, it will be JITed to actual x86-64 machine code (in the example each statement of the javascript is translated into one or two machine code instructions).
If you carefully craft you code, the produced code is still entirely valid, but the actual memory accessing functions aren't to far away.

As said, the code is valid, if you mentally trace through it :
- if the provided index is within bound of the "simpleByte" array, the rest of the step will get executed (including the write, which is forced to stay within bounds of the target "probe" array).
- if the provided index is out-of-bound, the conditional will be false, and the conditional jump will skip the entire block, nothing bad happens.

But when executed on a deeply pipelined CPU that does speculative execution :
- before the condition has finished getting executed (it takes some time: it needs to read the value of the lenght from memory, compare it with index, and only then do the jump), the CPU will try to feed instructions in the pipeline.
- its best guess is that the execution will run through (based on some predictors: e.g. code jumping backward is usually loops and is likely to be taken most of the time (except on the last iteration), code jumping forward is usually error checks and usually not jumping - error happening less often than normal execution. That's a real-world heuristic used in some processors).
- so it begins preparing the next instruction, and the instructions afterward.
- by the time that the "if" condition finished (the compare and conditional jump are executed), the rest of the instructions might be well into the pipeline
- that means that the memory page of the target "probe" array might already have been moved into the cache, to be ready to be written if the condition was actually correct.

So even if you call this function with a too-big index, even if the CPU throws away all the work it has done wrongly due to erroneous speculation ("probe" array will never actually get written to), there are still some measurable effect ( "probe" array will be in the cache, even if nothing ended up being written to it).

So, if you call this function with beyond-boundary index, you'll end up with a situation where nothing is written to "probe" BUT the specific page (which depends on the content of the out-of-bound location) were "probe" would have been written ends up being stored into cache.

If you use a stupidly big enough index, you might end up accessing something which is way beyond the limit of what the javascript code is supposed to access.
So in short, even if you don't have pointers to read at an arbitrary address, you can ask javascript to read an arbitrary point way beyond the end of an array, and even if there's a boundary check (here explicit in the javascript example), due to speculative execution the CPU will attempt to peek at that arbitrary point anyway.

Now if you repeat this read a lot, and then try to time in turn which part of "probe" is more often faster to read from (because it was already loaded into cache by the previous function), you can guess what that arbitrary point of memory contained.

(i.e.: you choose a random index "0xdeadbeef".
Then 10000 in a row, you call the function with the invalid index and then read "probe[0]", you time it and get XX ms.
Then run it again 10000 in a row, but this time read "probe[4096]". You time it and get YY ms, rought in