4 ms·
https://googleprojectzero.blogspot.com/2019/04/virtually-unlimited-memory-escaping.html https://googleprojectzero.blogspot.com/2019/04/virtually-unl... one of t
by kdma 5y ago
https://googleprojectzero.blogspot.com/2019/04/virtually-unlimited-memory-escaping.html https://googleprojectzero.blogspot.com/2019/04/virtually-unl...
one of the many public browser RCE.
Or look for the ps5 jailbreaks, the browser is the common denominator for most systems and its leaky as hell given that JS is dynamically typed and everything gets JIT-ed to hell (https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/ https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/) most exploits I've seen are about tricking webkit into type mismatching + JIT "invalidation".
WASM open this hole even wider
- the-smug-one 5y agoHow would the statically typed WASM open an even wider hole? Assuming you mean that the size of wasm's hole is larger than js, not that their combined holes are larger than either one.
- sitkack 5y agoWasm has more control over time and memory access than JS does. From a capabilities model, it is more secure, but from a threat model due to side channels, Wasm is a more effective tool than JS. This thread discusses SAB (shared array buffer) and Wasm side channels https://github.com/tc39/security/issues/3 https://github.com/tc39/security/issues/3
- emn13 5y agoBut to compensate those tricky features are sandboxed much more rigorously than JS is, e.g. https://developer.chrome.com/blog/enabling-shared-array-buffer/ https://developer.chrome.com/blog/enabling-shared-array-buff... - no SAB without site isolation.