Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

F3

github.com

Post reply on HN
Print view View original

81–90 of 141 posts

Re: F3

#81

Post by mort96 »

gavinray wrote: post #9

This bit is quite genius, rather than depend on a language-specific SDK/lib for working with the formats you can fallback to exported WASM methods if none exist: > "Each self-describing F3 file includes both the data and meta-data, as well as WebAssembly (Wasm) binaries to decode the data. Embedding the decoders in each file requires minimal storage (kilobytes) and ensures compatibility on any platform in case native…

I don't understand how that's supposed to work. What does the decoder decode into? That's gonna depend entirely on the kind of data, right? For some formats, it's gonna be a stream of bytes; for others, a 2D plane of pixels; others again will need vertexes, 2D planes of pixels and UV maps; for some, an object graph will make more sense.

Re: F3

#83

Post by Retr0id »

titzer wrote: post #79
Retr0id wrote: post #77

Earlier quoted context omitted.

WASM implementations are fairly mature now, but if there was e.g. an image file format with embedded WASM that needed to execute before you could view it, it would become the new low-hanging-fruit target for 0-click RCEs - whether it's exploiting the WASM engine itself or some other attack surface that's influenceable via it (See also, the FORCEDENTRY JBIG2 exploit).

That exploit targeted an integer overflow in a bespoke Apple sandboxing mechanism. Bespoke sandboxing mechanisms have weird bugs. Not that Wasm engines don't have bugs, but the whole point is to have an extremely solid, well-specified and efficient implementation of a widely accepted bytecode format. We can scope down the capabilities given to any program to a minimal set.

Bugs are near-inevitable, and mitigations are the last line of defence. Scripting engines are excellent for bypassing mitigations (iiuc in the case of the FORCEDENTRY exploit, it was used for adjusting ASLR'd offsets).

As a random example that's an area of personal interest to me, I know of 3 distinct methods of achieving userland ROP execution of the Nintendo Switch 2, and all three rely on the (ab)use of a scripting engine (even if they aren't a vulnerability in the scripting engine itself).

Re: F3

#84

Post by titzer »

7373737373 wrote: post #58
ratorx wrote: post #51

Earlier quoted context omitted.

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.

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

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.

Re: F3

#85

Post by computomatic »

ok123456 wrote: post #61
weinzierl wrote: post #44

Earlier quoted context omitted.

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.

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.

It seems like the WASM is simply a fallback if no other decoder is available. If the data source is untrusted, simply don’t run the WASM decoders.

“Some code is untrusted” does not mean code should never be executed. There are more use cases with trusted sources than untrusted.

Re: F3

#86

Post by titzer »

anygivnthursday wrote: post #70

My concern is, if decode fails I need to debug WASM added by some other party maybe containing random bugs. Maybe a library of standard decoders maintained and tested by the project could help, but then not sure if it kills the advantage of the flexibility it provides.

But Wasm has deterministic execution, so if decode fails for you, it should have failed for them. I.e. it's not a problem that your system has introduced; they should be able to reproduce the failure independent of any client.

Re: F3

#87

Post by 0x457 »

nine_k wrote: post #36
jasonjayr wrote: post #13

Earlier quoted context omitted.

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?

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

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.

Re: F3

#88

Post by kibwen »

ok123456 wrote: post #61
weinzierl wrote: post #44

Earlier quoted context omitted.

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.

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.

Denial-of-service is bad, but it's not in the same ballpark, the same sport, the same planet, or the same universe of bad as RCE.

Re: F3

#89

Post by ok123456 »

johncolanduoni wrote: post #73
ok123456 wrote: post #61

Earlier quoted context omitted.

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.

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.

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.

Re: F3

#90

Post by vouwfietsman »

zerobees wrote: post #60

Some folks described it as genius. I guess it's my turn to play the role of an annoying HN skeptic: I find it somewhat silly. Data compression formats are secondary to what you're planning to do with the data once decoded. An audio file is completely different than an SVG image. An embedded VM that decompresses video to raw pixels doesn't magically let you play that video in a text editor, so there's no radically new…

I don't think you have encountered the problems that this class of formats solves. Try looking up columnar storage formats, the pros and cons are pretty well defined these days. It is not meant for video decoding, indeed.
Post reply on HN