Post

For something so commonly used to parse complex, untrusted data (decompression), I wish we would seriously consider as an industry creating memory-safe implementations and sandboxing this code

This post is unavailable.

Logan Magee

@lberrymage.dev

Unfortunately, there are often tradeoffs of lower portability (Rust), less straightforward APIs (sandboxing), and/or lower performance (managed languages). But some of us are willing to make those tradeoffs.

25/11/24, 7:56 pm0 reposts1 like

Logan Magee

@lberrymage.dev

25 Nov 2024

Dropbox did this right I think. They wrote a brotli decompressor in a memory-safe langauge and sandboxed it. Granted, it takes effort to support platform-specific sandboxing capabilities, but isn't that worth the protection from vulnerabilities like these? dropbox.tech/infrastructu...

dropbox.techLossless compression with Brotli in Rust for a bit of Pied Piper on the backend

Logan Magee

@lberrymage.dev

25 Nov 2024

My opinion is that unless memory safe implementations and sandboxing become defaults directly in consumer libraries, the overall issue won't significantly improve. Developers shouldn't need to know that "if this ZIP library has a bug, a bad file could hack my machine." It's not intuitive.

Logan Magee

@lberrymage.dev

25 Nov 2024

I have seriously considered writing a memory-safe Zstandard decompressor because otherwise a single bad upstream zstd bug could spell RCE for tens of thousands of my app users. Decompression libraries are the most significant reason I sandboxed Ina for Accrescent. lberrymage.dev/posts/ina-pa...

lberrymage.devIna, Part 1: Smaller, faster, and safer software updates for AccrescentIntroduction Well! It’s been a long time since I’ve shared an Accrescent update here (most development discussion takes place in our Matrix rooms), but today I have a big one: we’ve made significant p...