3 ms·

So attackers don't have to craft specially corrupted files? They can just include the code to perform the attack in the data file itself?

arcfour 4mo ago
Yes...my first thought. No way in hell anyone actually trusts this. (And as if we didn't trust the compiler enough already!)
- Omega359 4mo ago
  Meh, it's not that bad. Pretty simple to block inline wasm and to use well known external decoders.
  - arcfour 4mo ago
    But that is 97% of the value proposition.
doctorpangloss 4mo ago
But the WASM runs in the sandbox! It only has access to some files, your display, inputs, ... nothing insecure at all!
- gavinray 4mo ago
  WASM runs in a confined memory space allocated for the program. There is no I/O or host address space access. You need to run a WASI environment for that.
nine_k 4mo ago
Does WASM have built-in I/O? If not, all that a decoder would be able to do is to decode into a buffer.
- 0x457 4mo ago
  All WASM can do is transfer bag of bytes between module runtime and host. So yes, so yeah it can just decode into a buffer. Even you use wasm components to give it I/O, you can still make these go to buffer.
weinzierl 4mo ago
WASM has strong tried and proven sandboxing. We basically can build on nearly 30 years of experience. The decoders don't need a lot of access, they can basically be pure functions. If this will pan out security-wise I don't know. I'm more worried that it will be so slow that no one will use it. Interesting idea, though, and I can see applications outside of the "big data" realm this apparently targets.
- bilekas 4mo ago
  > The decoders don't need a lot of access, they can basically be pure functions They don't currently either do they? It's the tight coupling of the interface layer no? I'm not sure this would be faster, or more secure so reliability might be the best usecase?
- ok123456 4mo ago
  How do you prevent compression bomb attacks when files can define their own compression functions? You could have some kind of OOM killer, but that will be a "footgun" that people who are actually doing "big data" will constantly shoot. This pretty much kills any ingestion pipeline where the source is untrusted.
  - johncolanduoni 4mo ago
    OOM killing in WebAssembly is trivial, since it’s all in a growable linear memory. All the runtimes I’m aware of have a simple maximum memory setting, and they’ll trap any allocation requests after that point.
    - titzer 4mo ago
      And many of them have built-in gas metering, so you can time out the decode if it runs too many instructions.
    - ok123456 4mo ago
      For images, it makes sense: people dealing with 16k x 16k PNGs are uncommon. Give them an error message that tells them the setting to bump. But what should be the threshold for "big data"? I'm sure it will follow Zipf's Law, but the tail will be fatter.

arcfour 4mo ago

Yes...my first thought. No way in hell anyone actually trusts this. (And as if we didn't trust the compiler enough already!)

Omega359 4mo ago
Meh, it's not that bad. Pretty simple to block inline wasm and to use well known external decoders.
- arcfour 4mo ago
  But that is 97% of the value proposition.

doctorpangloss 4mo ago

But the WASM runs in the sandbox! It only has access to some files, your display, inputs, ... nothing insecure at all!

gavinray 4mo ago
WASM runs in a confined memory space allocated for the program. There is no I/O or host address space access. You need to run a WASI environment for that.

nine_k 4mo ago

Does WASM have built-in I/O? If not, all that a decoder would be able to do is to decode into a buffer.

0x457 4mo ago
All WASM can do is transfer bag of bytes between module runtime and host. So yes, so yeah it can just decode into a buffer. Even you use wasm components to give it I/O, you can still make these go to buffer.

weinzierl 4mo ago

WASM has strong tried and proven sandboxing. We basically can build on nearly 30 years of experience. The decoders don't need a lot of access, they can basically be pure functions. If this will pan out security-wise I don't know. I'm more worried that it will be so slow that no one will use it. Interesting idea, though, and I can see applications outside of the "big data" realm this apparently targets.

bilekas 4mo ago
> The decoders don't need a lot of access, they can basically be pure functions They don't currently either do they? It's the tight coupling of the interface layer no? I'm not sure this would be faster, or more secure so reliability might be the best usecase?
ok123456 4mo ago
How do you prevent compression bomb attacks when files can define their own compression functions? You could have some kind of OOM killer, but that will be a "footgun" that people who are actually doing "big data" will constantly shoot. This pretty much kills any ingestion pipeline where the source is untrusted.
- johncolanduoni 4mo ago
  OOM killing in WebAssembly is trivial, since it’s all in a growable linear memory. All the runtimes I’m aware of have a simple maximum memory setting, and they’ll trap any allocation requests after that point.
  - titzer 4mo ago
    And many of them have built-in gas metering, so you can time out the decode if it runs too many instructions.
  - ok123456 4mo ago
    For images, it makes sense: people dealing with 16k x 16k PNGs are uncommon. Give them an error message that tells them the setting to bump. But what should be the threshold for "big data"? I'm sure it will follow Zipf's Law, but the tail will be fatter.