5 ms·
Wasm can be sandboxed. Its a safe as visiting a website with javascript.
by themerone 1y ago
Wasm can be sandboxed. Its a safe as visiting a website with javascript.
- orangeboats 1y agoCan't the decompressor still produce a malicious uncompressed file?
- tlb 1y agoAny decompressor can produce a malicious file. Just feed a malicious file to the compressor.
- orangeboats 1y agoYes, but currently the decompressors we use (so things like zstd, zlib, 7z) come from a mostly-verifiable source -- either you downloaded it straight from the official site, or you got it from your distro repo. However, we are talking about an arbitrary decompressor here. The decompressor WASM is sandboxed from the outside world and it can't wreak havoc on your system, true, but nothing stops it from producing a malicious uncompressed file from a known good compressed file.
- yorwba 1y agoIf the decompressor is included in the compressed file and it's malicious, the file can hardly be called known good.
- tecleandor 1y agoBut also I guess the logic of the decompressor could output different files in different occasions, for example, if it detects a victim, making it difficult to verify.
- viraptor 1y agoIf it can "detect a victim", then the sandbox is faulty. The decompressor shouldn't see any system details. Only the input and output streams.
- mort96 1y agoThe format-specific decompressor is part of the compressed file. Nothing here crosses a security boundary. Either the compressed file is trustworthy and therefore decompresses into a trustworthy file, or the compressed file is not trustworthy and therefor decompresses into a non-trustworthy file. If the compressed file is malicious, it doesn't matter whether it's malicious because it originated from a malicious uncompressed file, or is malicious because it originated from a benign uncompressed file and the transformation into a compressed file introduces the malicious parts due to the bundled custom decompressor.
- jo-m 1y agoSo, not very safe.