upvote

points

by verdverm2 hours ago |
comments
upvoteby mirashii2 hours ago|
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.
reply
upvoteby msla2 hours ago|
prev|
next
[-]
> Is embedding executable code into a file a security risk?

Yes, which is why nobody uses PDFs.

reply
upvoteby NooneAtAll358 minutes ago|
parent|
next
[-]
which is why no sane pdf viewer implements executable features*
reply
upvoteby bguebert49 minutes 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.
reply
upvoteby nine_k1 hours ago|
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.

reply
upvoteby cmiles741 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.

reply
upvoteby tedd4u1 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...

reply
upvoteby gavinray2 hours ago|
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.

reply
upvoteby jedberg2 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".
reply
upvoteby gavinray2 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.

reply
upvoteby jedberg1 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.
reply
upvoteby ratorx2 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.

reply
upvoteby gavinray1 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.

reply
upvoteby ratorx1 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.
reply
upvoteby 73737373731 hours ago|
parent|
[-]
There exist Wasm interpreters capable of limiting the number of instructions executed.
reply
upvoteby titzer1 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.
reply
upvoteby bguebert45 minutes 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.
reply
upvoteby jastanton2 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

reply
upvoteby outside12342 hours ago|
parent|
prev|
next
[-]
I mean can't we say the same thing about sending around a .exe though?
reply
upvoteby bluejekyll2 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.
reply
upvoteby gavinray2 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.

reply
upvoteby jastanton2 hours ago|
parent|
prev|
[-]
exactly
reply