The associated March 2021 blog post mentioned implementing multiple PoCs abusing different timers; the one chosen was verified "on Chrome 88 on an Intel Skylake CPU", which was released January 2021.
A cursory search did not find what further mitigations have been implemented since 2021.
So in the end it turns out there doesnt exist "a demo page you could use right now to check if you are susceptible" after all because browsers removed attack surface (precise timers).
> So in the end it turns out there doesnt exist "a demo page you could use right now to check if you are susceptible" after all because browsers removed attack surface
The original claim you made was "[the original attacks] didn't [work in javascript], otherwise there would be a demo page".
We have shown you such a page. You are not susceptible to that original attack anymore. Congrats. Isn't that all you were asking for? How have we not proven exactly that exists?
We haven't shown you that you are still presently susceptible to anything of course, but that's not what you were claiming.
And it's of course impossible to prove that you are not susceptible to any bug whatsoever, though I don't think many people would be surprised if there were still sources of accurate timing left in the browser
uBlock can inject this to every webpage you visit. The distinction is you can disable WebAssembly and >99.99% of the web will run like nothing happened.
Browsers have since added their own mitigations. Chrome has certainly come up with their own set of mitigations [0].
Nonetheless, a lot of hardware still remains unpatched and vulnerable. Do you install games? Do you install mods to your games? Do you fully trust every game author and mod author? Pro tip: you shouldn't; games can do it even easier. Don't do your business or finances on your gaming PC.
[!] error: could not infer memory layout
[] retrying. (2 retries left)
[!] error: could not infer memory layout
[] retrying. (1 retries left)
[!] error: could not infer memory layout
[!] no retries left
Btw some parts (maybe whole thing??) uses WebAssembly and not just js.
Wasm is trivially accessible from JavaScript, so it's not unreasonable to conflate the two, even if its technically incorrect. Wasm also can't do anything that JS couldn't already do; it's simply more convenient in many cases (and maybe somewhat faster at runtime) to write code in C/C++/Rust/whatever and compile it to Wasm than to write the code in JS. You could (and still can) compile these languages to asm.js instead, in which case the code would actually be JS, albeit a particularly weird dialect.
The site pretty clearly says it works on Chrome 88, on Linux. Chrome 91 reduced the resolution of performance.now significantly, which likely broke this website (https://developer.chrome.com/blog/cross-origin-isolated-hr-t...). You're also trying this out on Windows, which is also not supported by the demo page in its default configuration.
But also: this was a demo page put together by a random security researcher on their own, based on a vulnerability from a year ago. It's not a reflection of what a motivated attacker could do with a sufficiently powerful exploitation primitive (say, this Retbleed attack).
I can't speak to what that error is but Chrome 96 appears to be from Nov '21 at the earliest which would include a large number of these mitigations.
w.r.t. js vs web asm: I could be wrong but I think V8 is the engine involved with webassembly as well so I'm not sure the wa vs js distinction matters here, but even so my main point is that there were significant software mitigations put into place in the browser. I'd expect reproducing this attack today would be difficult.
no they didnt, otherwise there would be a demo page you could use right now to check if you are susceptible