4 ms·

It may be possible, by exploiting bugs in the cache control logic of the processor. If there is a bug that is predictable enough to make a controlled redirectio

It may be possible, by exploiting bugs in the cache control logic of the processor. If there is a bug that is predictable enough to make a controlled redirection of a cache line write, it may not matter if the source of the contention is in non executable (data) memory. If all you need to do is get contention at some cache line in a certain way, you could probably do that with string processing code running in an interpreter. You'd need to overcome address space randomization but apparently there are reflection techniques that allow that to some extent. In any case, I'd wait for confirmation from a white hat researcher who knows their shit, but I wouldn't reject out of hand that this is possible from javascript. CPU logic exploits are quite a different beast from the more common buffer overflows or OS flaw exploits.

duskwuff 14y ago
Hmm. Looking at the C exploit some more, it looks as though the exploit might be as simple as a very specific pattern of memory accesses from multiple threads, some of which are to code that's being executed. The memory access part is definitely doable from JS. Multiple threads is harder -- you might be able to do it by using web workers. Targeting memory access to a JIT-compiled function, however, would be the hard part; I don't see any way of doing that, short of executing the function (which would probably not have the desired effect).
- jasonwatkinspdx 14y ago
  Again, I'm way out of depth here, but if your javascript loop ran fast enough relative to the cache latency, you could perhaps create a similar effect. The key would be whether the cache logic flaw depended on requests from two distinct cores to the same cache line, or if it's something that multiple requests from a single core can excite. No clue if this is the case.

4 ms·

It may be possible, by exploiting bugs in the cache control logic of the processor. If there is a bug that is predictable enough to make a controlled redirectio

by jasonwatkinspdx 14y ago

duskwuff 14y ago
Hmm. Looking at the C exploit some more, it looks as though the exploit might be as simple as a very specific pattern of memory accesses from multiple threads, some of which are to code that's being executed. The memory access part is definitely doable from JS. Multiple threads is harder -- you might be able to do it by using web workers. Targeting memory access to a JIT-compiled function, however, would be the hard part; I don't see any way of doing that, short of executing the function (which would probably not have the desired effect).
- jasonwatkinspdx 14y ago
  Again, I'm way out of depth here, but if your javascript loop ran fast enough relative to the cache latency, you could perhaps create a similar effect. The key would be whether the cache logic flaw depended on requests from two distinct cores to the same cache line, or if it's something that multiple requests from a single core can excite. No clue if this is the case.