3 ms·

If you assume you just say the magic word ‘sandbox’ and everything is safe, then yes, security is a solved problem. This is however a prime example of the sayin

If you assume you just say the magic word ‘sandbox’ and everything is safe, then yes, security is a solved problem. This is however a prime example of the saying that in theory, there is no difference between theory and practice but in practice there is.

Dylan16807 3y ago
You're treating sandboxing like it's all the same, but it's not. Multimedia decoders are one of the absolute easiest things to sandbox. Webassembly was designed for sandboxing and even that's very overcomplicated for what a decoder needs. If we had standard headers, then reading metadata wouldn't be part of the decoder. The decoder would only need to take in bytes and output a bitmap, or take in bytes and output PCM audio. It doesn't need to be able to call any functions, or run any system calls, and the data it outputs can safely contain any bytes because nothing will interpret it. It's like taking the very core of webassembly and then not attaching it to anything. The attack surface is astoundingly small. You just need to give it a big array of memory and let it run arithmetic within that array, plus some control flow instructions. Easy to interpret, easy to safely JIT compile.
- tinus_hn 3y ago
  I suggest you try building it and see ‘just’ how easy it is.
  - Dylan16807 3y ago
    I have made secure emulators for simple CPUs before. Seriously, you only need a handful of opcodes and they only need to operate on a big array. It's hard to do wrong! The part of sandboxing that's hard is dealing with I/O, or giving useful tools to the sandboxed code, or implementing data structures for the sandboxed code. You don't need any of that for a multimedia decoder. You just let it manipulate its big block of bytes, and make sure you bounds check. A Java VM exposes tens of thousands of functions to the code inside it. A barebones sandbox exposes zero. It just waits for the HLT opcode. And when it gives you raw RGB data, or raw PCM data, there's no way to hide a triggerable malicious payload inside. If the code does something bad, the worst it can do is show you the wrong image.
    - tinus_hn 3y ago
      Yes, and you can also download a million projects like this, the sandbox exists. But my suggestion would be that you build a video codec out of it. Preferably one that has the properties the market demands: performance and energy efficiency.
      - Dylan16807 3y ago
        Not a codec, the only thing customized for this would be the container format. You'd use existing codecs, and the way you get good performance and energy efficiency on a video codec is by having a hardware implementation. Software decoding doesn't even come into that picture. As far as practical software decoding outside of battery-powered video, can I just point at webassembly? Especially the upcoming version with vector instructions. You could use normal webassembly, or even an extra-restricted version. It gets pretty good performance, and when you remove its ability to talk to the outside world it goes from pretty good to extremely good security.
        tinus_hn 3y ago
        The container format would be decoded by a sandboxed codec that can be found by decoding the container? WebAssembly codecs indeed exist, and they are impractical due to a lack in performance.
        Dylan16807 3y ago
        > The container format would be decoded by a sandboxed codec that can be found by decoding the container? The container parser would not be dynamically downloaded, and may or may not be sandboxed. We don't need a new container with almost every codec. We just need the new codec itself. > WebAssembly codecs indeed exist, and they are impractical due to a lack in performance. Mostly because they don't have vector instructions yet, I bet. But plenty of webassembly is within 50% of native, which is good enough for lots of things, which includes image decoding for sure.
        3y ago

Dylan16807 3y ago

You're treating sandboxing like it's all the same, but it's not. Multimedia decoders are one of the absolute easiest things to sandbox. Webassembly was designed for sandboxing and even that's very overcomplicated for what a decoder needs. If we had standard headers, then reading metadata wouldn't be part of the decoder. The decoder would only need to take in bytes and output a bitmap, or take in bytes and output PCM audio. It doesn't need to be able to call any functions, or run any system calls, and the data it outputs can safely contain any bytes because nothing will interpret it. It's like taking the very core of webassembly and then not attaching it to anything. The attack surface is astoundingly small. You just need to give it a big array of memory and let it run arithmetic within that array, plus some control flow instructions. Easy to interpret, easy to safely JIT compile.

tinus_hn 3y ago
I suggest you try building it and see ‘just’ how easy it is.
- Dylan16807 3y ago
  I have made secure emulators for simple CPUs before. Seriously, you only need a handful of opcodes and they only need to operate on a big array. It's hard to do wrong! The part of sandboxing that's hard is dealing with I/O, or giving useful tools to the sandboxed code, or implementing data structures for the sandboxed code. You don't need any of that for a multimedia decoder. You just let it manipulate its big block of bytes, and make sure you bounds check. A Java VM exposes tens of thousands of functions to the code inside it. A barebones sandbox exposes zero. It just waits for the HLT opcode. And when it gives you raw RGB data, or raw PCM data, there's no way to hide a triggerable malicious payload inside. If the code does something bad, the worst it can do is show you the wrong image.
  - tinus_hn 3y ago
    Yes, and you can also download a million projects like this, the sandbox exists. But my suggestion would be that you build a video codec out of it. Preferably one that has the properties the market demands: performance and energy efficiency.
    - Dylan16807 3y ago
      Not a codec, the only thing customized for this would be the container format. You'd use existing codecs, and the way you get good performance and energy efficiency on a video codec is by having a hardware implementation. Software decoding doesn't even come into that picture. As far as practical software decoding outside of battery-powered video, can I just point at webassembly? Especially the upcoming version with vector instructions. You could use normal webassembly, or even an extra-restricted version. It gets pretty good performance, and when you remove its ability to talk to the outside world it goes from pretty good to extremely good security.
      - tinus_hn 3y ago
        The container format would be decoded by a sandboxed codec that can be found by decoding the container? WebAssembly codecs indeed exist, and they are impractical due to a lack in performance.
        Dylan16807 3y ago
        > The container format would be decoded by a sandboxed codec that can be found by decoding the container? The container parser would not be dynamically downloaded, and may or may not be sandboxed. We don't need a new container with almost every codec. We just need the new codec itself. > WebAssembly codecs indeed exist, and they are impractical due to a lack in performance. Mostly because they don't have vector instructions yet, I bet. But plenty of webassembly is within 50% of native, which is good enough for lots of things, which includes image decoding for sure.
        3y ago