File format for what? Text, graphics, compiled code?
The future.
F3
31–40 of 141 posts
Re: F3
#32This 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…
Is embedding executable code into a file a security risk? My assumption is a yes
> Is embedding executable code into a file a security risk?
Yes, which is why nobody uses PDFs.
Re: F3
#33This 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…
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?
But the WASM runs in the sandbox! It only has access to some files, your display, inputs, ... nothing insecure at all!
Re: F3
#34Probably not a good idea to name your project “future” anything, if you expect that future to become the present.
Also, f3 is already “fight-flash-fraud”.
Re: F3
#35I love the idea, and I developed something similar of myself in the past (https://github.com/golddranks/kobuta), but... this reeks of slop. With Rust code, edition="2021" is a dead giveaway.
Re: F3
#36This 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…
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.
Re: F3
#37Earlier quoted context omitted.
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.
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".
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.
Re: F3
#38Earlier quoted context omitted.
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.
I mean can't we say the same thing about sending around a .exe though?
.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.
Re: F3
#39Re: F3
#40Earlier quoted context omitted.
Is embedding executable code into a file a security risk? My assumption is a yes
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.
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.