5 ms·
Well this definitely won't get exploited at all or lead to new strict limits on what Harfbuzz/WASM can do
by bastien2 2y ago
Well this definitely won't get exploited at all or lead to new strict limits on what Harfbuzz/WASM can do
- chena12 2y ago[dead]
- lxgr 2y agoWASM sandboxing is pretty good! Together with the presumably very limited API with which this can communicate with the outside world, I wouldn't be too concerned. To me, it's a great reminder that the line between well-sandboxed turing-complete execution environments and messy implementations of decoders for "purely declarative" data formats can be quite blurry. Said differently, I'd probably trust Harfbuzz/WASM more than the average obscure codec implementation in ffmpeg.
- pbmahol 2y agoIs there scientific proof of above claim such as "WASM sandboxing is pretty good!" ? At least most if not all ffmpeg decoders and demuxers are fuzzed all the time and any found issue is addressed.
- lxgr 2y agoFuzzing is good, robust sandboxing is better, I'd argue. There's just a much smaller surface area to cover for the latter. > Is there scientific proof of above claim such as "WASM sandboxing is pretty good!" ? I'm not aware of quantitative studies, but just from a design perspective, the surface that a WASM runtime presents seems intrinsically easier to defend than that of, say, the full Unix userspace that ffmpeg instances usually run in. Anecdotally, many high-profile iOS and Android vulnerabilities originated in some more or less obscure codec implementation.