Comment by bastien2
7 months ago
Well this definitely won't get exploited at all or lead to new strict limits on what Harfbuzz/WASM can do
7 months ago
Well this definitely won't get exploited at all or lead to new strict limits on what Harfbuzz/WASM can do
WASM 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.
Is 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.
Fuzzing 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.
[dead]