[gavinray]

There is no concept of "executable" vs "non-executable" content in a file.

A file is a bag of bytes. You can send those bytes to different things, like a text editor's content-stream, or as the input to a WASM interpreter.

What you decide to do with the bytes in a file is your own prerogative. Each byte is whatever you make of it.

[jedberg]

Sure, but when the standard says "read this file and execute the instructions you find at the beginning" that is more dangerous than "this is a file with data and your program needs to figure out how to read it".

[gavinray]

I guess it's a good thing that the F3 standard does not say "read this file and execute the instructions you find at the beginning", then?

The WASM encoders/decoders are embedded resources that exist as byte offsets in the file metadata, not header info.

[jedberg]

Ok if you want to be pedantic, the standard says, "if you can't read this file, go to the offset and then execute the code you find" which isn't functionally different from what I said.

[ratorx]

There’s a big difference in the expected use of a file. If the file is attacker provided, and the fallback path is being used, the attacker can embed whatever WASM payload they want into the file since the file will be “opened” by “execute this offset into the file”.

Compare that to JSON. The parser NEVER needs to execute arbitrary instructions. Parser might have bugs, but it avoids a whole class of issues.

[gavinray]

  >  the attacker can embed whatever WASM payload they want into the file since the file will be “opened” by “execute this offset into the file”.

And then do what with it?

WASM physically cannot interact with the underlying host or perform I/O -- you need a WASI environment for that.

[ratorx]

Putting aside the WASM sandboxing (I’m not familiar enough with it to understand how sandboxing works) there’s a DoS vector at least. Even regexes have had many DoS issues, and I can’t imagine WASM being easier to sandbox for DoS risk.

[7373737373]

There exist Wasm interpreters capable of limiting the number of instructions executed.

[titzer]

Many can, even if they have JITs, e.g. Wasmtime. Failing that, it's not that hard to add bytecode instrumentation that will count instructions and terminate early. Some execution platforms that utilize Wasm just inject bytecode instrumentation into guest programs before sending them to the Wasm engine. It's relatively easy to do and not that much overhead.

[bguebert]

I mean json might not be the best example since for a long time people would run json through a javascript engine to parse it but I can see your point.

[jastanton]

gotcha, so the vulnerability will be in some common libraries that attackers force some wasm fallback path with custom wasm instructions that when executed does something nefarious.

I'd say at worst it's setup for poor security

[outside1234]

I mean can't we say the same thing about sending around a .exe though?

[bluejekyll]

.exe has bindings to OS ABI and system calls, WASM doesn’t have this by default, it’s up to the VM to provide whatever environment the WASM executable needs, ideally there should be no system calls, no stdio, just instructions on how to interpret the file format.

[gavinray]

Double-clicking an ".exe" (or running it via a shell) is not the same as "bag of bytes", it's "send these bytes to an executable environment".

Doing `head foo.exe` is quite different than `run foo.exe`

If I encode executable instructions in "image.png" and then send them to an interpreter that runs those instructions, the file extension doesn't matter.

[jastanton]

exactly