you are right -- EROI and emissions are different. If you add in things like carbon capture, emissions go down but energy-in goes up. Would it make sense to extract and refine gasoline with net-0 emissions if it took more energy than you get out in gasoline? _maybe_, but I don't think its a clear yes!
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.
I think there is a straightforward path to having Browsix generically support the WebAssembly WASI system interface[0] -- any toolchain that emitted binaries targeting that would then work in Browsix without e.g. Emscripting needing to know anything about Browsix.
I'm one of the authors - its so exciting to see continued interest here!
The biggest problem with Browsix today stems from Spectre mitigations: Shared Array Buffers aren't enabled by default in browsers, and static hosting sites like GitHub Pages don't let you set the right COOP/COEP ( https://web.dev/coop-coep/ ) headers to get them enabled AFAICT.
Additionally, Browsix hasn't been updated in a while, although I still believe the idea is sound. I don't have a lot of time for Browsix these days, but it would be straightforward to update Browsix with WASI support which would free us from having to use a modified Emscripten toolchain (and instantly enable running Rust binaries under Browsix).
[edit]: for additional context: we use Shared Array Buffers to give the kernel and program a shared view of a process's address space to enable fast system calls between Web Workers and the kernel (running in the main browser thread/context). Without them performance is unacceptably slow, as things like read/write system calls (a) require several memcpys and (b) create a bunch of JS garbage. Additionally, without them there isn't a good way to "block" handling a syscall in a WebWorker (which we need to do for non-event-loop C/C++/Rust programs).
Weirdly enough, I was complaining about this exact issue this week. You can setup COOP/COEP in Github pages but you are still restricted to same domain for all resources. Which may or may not work in your case.
I've been working on a modified Emscripten runtime that treats threads as separate "programs" with their own memory, etc. Not an optimal solution at all but sometimes you need to hack your way around a problem.
How did you get COOP/COEP in Github pages? A quick search just now suggested it might be possible with a Service Worker[0], with the caveat that it may only work on _second_ load.
If I'm reading this right, it means Shared Array Buffers can get enabled by sites that are not GitHub Pages, eg, by spinning up one's preferred cloud hosting instance (DO AWS Azure etc).
If yes, then this appears in my mind as not a huge problem.
Yeah, 10 years later and all these Flash killers keep not having the tooling offered by it, while the workarounds to deal with security are so bothersome that in the end everyone ends up doing mobile native apps instead.
That's pretty right, with the addition that other things can target Browsix (like the gopherjs toolchain). Emscripten provides default implementations of a bunch of syscalls (and even a way to embed a file system), and we override those to instead do actual syscalls to a shared kernel (running in JS)
(author here) Without something like Browsix you have to make a choice: find a JavaScript library or implement the functionality you want to run client side, or run existing Unix programs and libraries (that expect a filesystem, to be able to fork children, etc) server side. If you run software server side, now you have to worry about containerizing/security as well as horizontal scaling.
Browsix addresses this by letting you run Unix programs directly in the browser, taking advantage of the significant compute power on peoples laptops (and even phones nowadays!), eliminating a whole class of security issues (software explicitly will only have access to the current users data in the browser tab) and scaling concerns.
(one of the authors here) it was written in Typescript from the start! Typescript eliminated a bunch of type confusion errors when developing the kernel, although the need to marshal data across a MessagePort means we have to do some casting and lose some safety.
Since it is written in Typescript, can parts of Browsix get compiled to Wasm instead of JS via AssemblyScript? Then at some point Browsix could run inside of any compatible wasm env and not just a browser tab?
I wouldn't say it's less compile-time type safety assuming you assert the type of the data as soon as you obtain it. Typescript doesn't give you runtime safety anyway, so I can't really imagine any better way short of adding types to the actual runtime and making the browser assert them across MessageEvent.
Thanks for the response! I don't know what the MessagePort is, but have dealt with the pains of marshaling/unmarshaling in a browser caching library I wrote that stores app data in localStorage (which is string-only)
Can you compare `tcmalloc` to e.g. tcmalloc dynamically loaded, or jemalloc specified with Bazel's malloc option? It is unclear from the post whether the wins are improvements from the internal Google improvements to tcmalloc post-gperftools, or to reduction in overhead from bypassing the PLT
