3 ms·
> If they were going to run the whole thing in a SECCOMP container anyway, there is little damage a compromised C library could do. Not really. For instance,
by Jweb_Guru 10y ago
> If they were going to run the whole thing in a SECCOMP container anyway, there is little damage a compromised C library could do.
Not really. For instance, a compromised library can still rewrite the file you're storing in DropBox to contain different contents, which could ultimately result in remote code execution when you redownloaded it. Seccomp only makes sure the decompression server is safe from a rogue process.
- daniel_rh 10y agoThe file's sha256sum can be verified before the file is sent to any users, so there's no chance of RCE there, even with a hypothetical C brotli-- but a reproducible decompression is key. Additionally, if you want to do the decompression on client-side, facilities like SECCOMP simply may not be available on that platform. And in that case, having a language like Rust to guard against RCE is an excellent idea. Also it is easiest to maintain the same code running on all platforms rather than C code where SECCOMP is available and Rust code where it is not.
- saynsedit 10y agoIs the brotli decompression step really the most dangerous vector on the client-side? What about all the non-verified client-side native code that actually interprets file data? From a practical perspective using the C code doesn't deteriorate existing conditions and using the Rust code doesn't improve them.
- deleted 10y ago[deleted]