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

▲ mirashii 5 hours ago | parent | next [-]

That would be why it chose a VM that is explicitly designed for sandboxing rather than native executable code or similar, the risk can be minimized by reducing the surface area available to that executable code to almost nothing.

▲

jayd16 2 hours ago | parent [-]

You still have the halting problem to solve to prevent denial of service.

	▲	adwn an hour ago \| parent [-]
		Solving the halting problem is neither necessary nor sufficient to prevent DoS attacks. It isn't necessary, because settings timeouts or other resource restrictions works way better to prevent DoS. It isn't sufficient, because even if you can prove that a program will halt at some point, this alone doesn't tell you how long it will take. What good does it do to know that the program will run for 10 years before it halts? By that time, service will already have been denied. Even turning hash table lookups from O(1) to O(n) (still very much terminating!) can result in a DoS.

▲ msla 4 hours ago | parent | prev | next [-]

> Is embedding executable code into a file a security risk?

Yes, which is why nobody uses PDFs.

	▲	NooneAtAll3 3 hours ago \| parent \| next [-]
		which is why no sane pdf viewer implements executable features*
	▲	bguebert 3 hours ago \| parent \| prev [-]
		I mean I disable javascript embedded in pdf and feel like it would have been better to not have that feature. It would spare people from the invoice.pdf email attachment viruses because most people had assumed pdf isn't going to be as bad as an exe.

▲ nine_k 4 hours ago | parent | prev | next [-]

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.

	▲	cmiles74 4 hours ago \| parent \| next [-]
		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.
	▲	tedd4u 4 hours ago \| parent \| prev [-]
		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...

▲ gavinray 5 hours ago | parent | prev [-]

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

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

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

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

▲ jastanton 4 hours ago | parent | prev | next [-]

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

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

	▲	bluejekyll 4 hours ago \| parent \| next [-]
		.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 4 hours ago \| parent \| prev \| next [-]
		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 4 hours ago \| parent \| prev [-]
		exactly

▲ sieabahlpark 4 hours ago | parent | prev [-]

[dead]