Conversation

I'm seeing something of a "sandboxing is dead" narrative popping up in light of new real-world attacks and growing interest in memory-safe development approaches (e.g. Rust). This framing seems inherently contradictory to me, and I would like to explain why. 1/9

116

Replying to

Even Rust people don’t think Rust is a complete alternate to sandboxing (anymore). Spectre and the like directly attack language-based safety. I actually don’t even understand how there could be a debate about this at this point.

Replying to

and

Can also still have vulnerabilities in the much smaller amount of unsafe code trusted to maintain memory safety itself. Having only a tiny fraction of code trusted to maintain it instead of all doesn't mean those problems completely go away. Compiler/runtime bugs exist too.

Replying to

and

There are also non-memory-safety bugs protected against by a sandbox. Memory safety and lack of dynamic code execution eliminate most remote code execution issues but those are not the only kinds of vulnerabilities. Can have data / file access vulnerabilities and other issues.

6:39 AM · Apr 10, 2021Twitter Web App

Replying to

and

Against memory corruption specifically, memory safe languages + exploit mitigations + sandboxing work together. You don't want to switch to having no exploit mitigations and then have it be incredibly easy to exploit the rare memory corruption bugs still found in low-level code.