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

41–50 of 141 posts

Re: F3

#41

Post by gavinray »

ratorx wrote: post #40
gavinray wrote: post #18

Earlier 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.

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.

  >  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.

Re: F3

#42

Post by nine_k »

verdverm wrote: post #12
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…

Is embedding executable code into a file a security risk? My assumption is a yes

TrueType and OpenType fonts include code executed by a VM to even render them. This wasn't a viable source of attacks so far, due to the properly limited nature of the VMs.

Maybe I would pick the eBPF VM instead, with all its limiting and verifying mechanics.

Re: F3

#43

Post by gavinray »

doctorpangloss wrote: post #33
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?

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

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.

Re: F3

#44

Post by weinzierl »

jasonjayr wrote: post #13
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…

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?

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.

Re: F3

#45

Post by Groxx »

Hm. I can kinda see it replacing self-extracting EXEs, but a lot of why you choose specific file formats is for specific features they offer - any self-describing system can fall into "there are too many competing features and nobody handles them all" exactly as easily as any other format.

Like, can this file be efficiently mmap'd? Maybe if it emulates tar internally, but you don't know until you run it. Can it be seeked to specific bytes to only decompress part? It only supports a pre-release version of ISO-36898533 seeking, and your file library dropped support for it 6 years ago. If I rewrite 1MB in the middle, can it only change those pages on disk (and maybe an index), or do I have to rewrite the whole thing? Well the wasm blob supports 97 different APIs for it (there are 35 copies of one with different names), so it's larger than the data (but nobody paid attention to that), so you have 19 options that you recognize, but your CPU's native WASM accelerator only handles two or three so you've still got to specialize your code heavily.

At least with "*.tar.gz" you have some idea of what's possible.

Re: F3

#46

Post by sieabahlpark »

gavinray wrote: post #18
verdverm wrote: post #12

Earlier 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.

[dead]

Re: F3

#48

Post by tedd4u »

nine_k wrote: post #42
verdverm wrote: post #12

Earlier quoted context omitted.

Is embedding executable code into a file a security risk? My assumption is a yes

TrueType and OpenType fonts include code executed by a VM to even render them. This wasn't a viable source of attacks so far, due to the properly limited nature of the VMs. Maybe I would pick the eBPF VM instead, with all its limiting and verifying mechanics.

There are many documented, exploited-in-the-wild font-file attacks (one example in 1]). Apple is re-writing their font interpreter specifically to improve security. [2]

[1] https://www.bleepingcomputer.com/news/security/facebook-disc...

[2] https://blakecrosley.com/blog/truetype-hinting-swift-migrati...

Re: F3

#49

Post by cmiles74 »

nine_k wrote: post #42
verdverm wrote: post #12

Earlier quoted context omitted.

Is embedding executable code into a file a security risk? My assumption is a yes

TrueType and OpenType fonts include code executed by a VM to even render them. This wasn't a viable source of attacks so far, due to the properly limited nature of the VMs. Maybe I would pick the eBPF VM instead, with all its limiting and verifying mechanics.

https://learn.microsoft.com/en-us/security-updates/SecurityB...

> This security update resolves a publicly disclosed vulnerability in Microsoft Windows. The vulnerability could allow remote code execution if a user opens a specially crafted document or visits a malicious Web page that embeds TrueType font files.

> This security update is rated Critical for all supported releases of Microsoft Windows. For more information, see the subsection, Affected and Non-Affected Software, in this section.

> The security update addresses the vulnerability by modifying the way that a Windows kernel-mode driver handles TrueType font files. For more information about the vulnerability, see the Frequently Asked Questions (FAQ) subsection for the specific vulnerability entry under the next section, Vulnerability Information.

Post reply on HN