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 4 hours ago | parent | next [-]

  >  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 4 hours ago | parent [-]

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 4 hours ago | parent [-]

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

	▲	titzer 3 hours ago \| parent [-]
		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 3 hours ago | parent | prev [-]

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.