4 ms·

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

mirashii 4mo ago
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 4mo ago
  You still have the halting problem to solve to prevent denial of service.
  - adwn 4mo ago
    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.
    - jayd16 4mo ago
      It was just a joke, bud. I agree that a timeout would likely be fine depending on the situation. This is basically just a web page with javascript.
gavinray 4mo ago
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.
- outside1234 4mo ago
  I mean can't we say the same thing about sending around a .exe though?
  - jastanton 4mo ago
    exactly
  - gavinray 4mo ago
    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.
  - bluejekyll 4mo ago
    .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.
- jastanton 4mo ago
  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
- jedberg 4mo ago
  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 4mo ago
    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.
msla 4mo ago
> Is embedding executable code into a file a security risk? Yes, which is why nobody uses PDFs.
- NooneAtAll3 4mo ago
  which is why no sane pdf viewer implements executable features*
- bguebert 4mo ago
  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 4mo ago
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.
- tedd4u 4mo ago
  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-discloses-freetype-2-flaw-exploited-in-attacks/ https://www.bleepingcomputer.com/news/security/facebook-disc... [2] https://blakecrosley.com/blog/truetype-hinting-swift-migration https://blakecrosley.com/blog/truetype-hinting-swift-migrati...
- cmiles74 4mo ago
  https://learn.microsoft.com/en-us/security-updates/SecurityBulletins/2011/ms11-087?redirectedfrom=MSDN 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.

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 4mo ago
You still have the halting problem to solve to prevent denial of service.
- adwn 4mo ago
  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.
  - jayd16 4mo ago
    It was just a joke, bud. I agree that a timeout would likely be fine depending on the situation. This is basically just a web page with javascript.

gavinray 4mo ago

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.

outside1234 4mo ago
I mean can't we say the same thing about sending around a .exe though?
- jastanton 4mo ago
  exactly
- gavinray 4mo ago
  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.
- bluejekyll 4mo ago
  .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.
jastanton 4mo ago
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
jedberg 4mo ago
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 4mo ago
  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.

msla 4mo ago

> Is embedding executable code into a file a security risk? Yes, which is why nobody uses PDFs.

NooneAtAll3 4mo ago
which is why no sane pdf viewer implements executable features*
bguebert 4mo ago
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 4mo ago

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.

tedd4u 4mo ago
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-discloses-freetype-2-flaw-exploited-in-attacks/ https://www.bleepingcomputer.com/news/security/facebook-disc... [2] https://blakecrosley.com/blog/truetype-hinting-swift-migration https://blakecrosley.com/blog/truetype-hinting-swift-migrati...
cmiles74 4mo ago
https://learn.microsoft.com/en-us/security-updates/SecurityBulletins/2011/ms11-087?redirectedfrom=MSDN 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.