3 ms·

This seems to theorize an attack where you are interested in particularly data of the particularly visited website, and at the same time assuming that the attac

by anyfoo 1y ago

This seems to theorize an attack where you are interested in particularly data of the particularly visited website, and at the same time assuming that the attack would have to be carried out on the same website. The vulnerability however allows arbitrary reading of any memory in the system in at least some circumstances, the presented PoC (https://www.youtube.com/watch?v=jrsOvaN7PaA https://www.youtube.com/watch?v=jrsOvaN7PaA ) demonstrates this by literally searching memory for the system's /etc/shadow and dumping that. Whether the attack is practical using JS instead of a compiled C program is unknown to me, but if it is, it's not clear to me why the attacker would need to inject JS code into other websites or know what addresses to target. (If it is not, the question is moot.)

ActorNightly 1y ago
>The vulnerability however allows arbitrary reading of any memory in the system in at least some circumstances, the presented PoC The PoC uses compiled C code. I hope I don't have to explain the difference between C code that runs on the system versus JS code that runs in the context of the browser...
- deleted 1y ago
  [deleted]
- anyfoo 1y ago
  Well that only depends on what gadgets happen to be available, doesn't it? Both C and JS get compiled down to machine code. I personally would not trust that you couldn't, in the most extreme case, get close enough to the kernel (like the PoC does through system calls) to mispredict it into leaking any kernel-mapped memory through a timing side channel. And nowadays, kernels typically map almost all physical memory in their shared address space (it's not too expensive in a 64 bit address space). EDIT: See my extended reasoning here: https://news.ycombinator.com/item?id=43991696 https://news.ycombinator.com/item?id=43991696
  - ActorNightly 1y ago
    There is no gadget in JS that lets you access arbitrary memory address in the system. You can create an array and then access it past bounds in the sense that branch predictor will execute this code and in theory load the address to cache, but the memory start of that array is going to be arbitrary. The JS engine doesn't allow you (even in web assembly) to access raw memory by value, and there is always a translation layer.
    - anyfoo 1y ago
      Again, I don't think I understood yet why the JS code needs to create actual pointers accessing arbitrary memory for the attack to work, instead of benignly passing down arbitrary integer values far enough into (say) the kernel and mispredicting into code that would use these arbitrary values to be dereferenced as pointers, elaborated here: https://news.ycombinator.com/item?id=43991973 https://news.ycombinator.com/item?id=43991973
      - ActorNightly 1y ago
        Because you have no way of computing how "far" you need past the array length to access, because you have no idea where the first value is in memory, and you can read backwards from the memory location assigned to you by the JS engine. So if you get INSANELY lucky and make cache eviction of arbitrary memory addresses work, and you can get around other applications accessing the memory and putting values back in the cache, you are still left with a bunch of random hex values, and you have no idea where the key is, or even if its in those values (in case the memory of the target process is "behind" chrome) With C code, you can pretty much reference any memory location, so you can make things work.
        cdman 1y ago
        Spectre was shown to be exploitable from Javascipt: https://www.zdnet.com/article/google-this-spectre-proof-of-concept-shows-how-dangerous-these-attacks-can-be/ https://www.zdnet.com/article/google-this-spectre-proof-of-c... - making the bet that this won't be shown the same is not a safe wager I would say :) (especially that Javascript also includes stuff like WebAssembly).

by anyfoo 1y ago

ActorNightly 1y ago

>The vulnerability however allows arbitrary reading of any memory in the system in at least some circumstances, the presented PoC The PoC uses compiled C code. I hope I don't have to explain the difference between C code that runs on the system versus JS code that runs in the context of the browser...

deleted 1y ago
[deleted]
anyfoo 1y ago
Well that only depends on what gadgets happen to be available, doesn't it? Both C and JS get compiled down to machine code. I personally would not trust that you couldn't, in the most extreme case, get close enough to the kernel (like the PoC does through system calls) to mispredict it into leaking any kernel-mapped memory through a timing side channel. And nowadays, kernels typically map almost all physical memory in their shared address space (it's not too expensive in a 64 bit address space). EDIT: See my extended reasoning here: https://news.ycombinator.com/item?id=43991696 https://news.ycombinator.com/item?id=43991696
- ActorNightly 1y ago
  There is no gadget in JS that lets you access arbitrary memory address in the system. You can create an array and then access it past bounds in the sense that branch predictor will execute this code and in theory load the address to cache, but the memory start of that array is going to be arbitrary. The JS engine doesn't allow you (even in web assembly) to access raw memory by value, and there is always a translation layer.
  - anyfoo 1y ago
    Again, I don't think I understood yet why the JS code needs to create actual pointers accessing arbitrary memory for the attack to work, instead of benignly passing down arbitrary integer values far enough into (say) the kernel and mispredicting into code that would use these arbitrary values to be dereferenced as pointers, elaborated here: https://news.ycombinator.com/item?id=43991973 https://news.ycombinator.com/item?id=43991973
    - ActorNightly 1y ago
      Because you have no way of computing how "far" you need past the array length to access, because you have no idea where the first value is in memory, and you can read backwards from the memory location assigned to you by the JS engine. So if you get INSANELY lucky and make cache eviction of arbitrary memory addresses work, and you can get around other applications accessing the memory and putting values back in the cache, you are still left with a bunch of random hex values, and you have no idea where the key is, or even if its in those values (in case the memory of the target process is "behind" chrome) With C code, you can pretty much reference any memory location, so you can make things work.
      - cdman 1y ago
        Spectre was shown to be exploitable from Javascipt: https://www.zdnet.com/article/google-this-spectre-proof-of-concept-shows-how-dangerous-these-attacks-can-be/ https://www.zdnet.com/article/google-this-spectre-proof-of-c... - making the bet that this won't be shown the same is not a safe wager I would say :) (especially that Javascript also includes stuff like WebAssembly).