3 ms·

> I don't ever want to run untrusted code from the internet outside of a sandbox ever again WASM is great, but I think it's a wrong approach for sandboxing pro

> I don't ever want to run untrusted code from the internet outside of a sandbox ever again WASM is great, but I think it's a wrong approach for sandboxing problem. It's technically possible to sandbox native applications (compiled into target machine code) using OS-builtin mechanisms, but it's not done for compatibility reasons, because this is the way things were done last 50 years or so.

tancop 4mo ago
sandboxing native apps just gives you security. with wasm you also get a single portable binary that can run on x86 windows, arm64 linux and in your browser with zero modification. you dont need to write platform specific code or use third party frameworks.
- Panzerschrek 4mo ago
  > you dont need to write platform specific code You don't need to write platform-specific code if you use some cross-platform framework. For simple programs it may be enough to use only the standard library of your language of choice. > single portable binary that can run on x86 windows, arm64 linux and in your browser with zero modification It has little value. Compiling a separate binary for each OS isn't that hard, since only a handful of architectures and operating systems are actually in use. Using an abstract cross-platform binary (like WASM) in the other hand adds extra performance costs and other user-side overhead, which isn't strictly necessary.
  - zcw100 4mo ago
    > You don't need to write platform-specific code if you use some cross-platform framework. For simple programs it may be enough to use only the standard library of your language of choice. That's a circular argument and "some" is doing a lot of work there. What cross-platform framework would you be referring to? > It has little value. Compiling a separate binary for each OS isn't that hard, since only a handful of architectures and operating systems are actually in use. Using an abstract cross-platform binary (like WASM) in the other hand adds extra performance costs and other user-side overhead, which isn't strictly necessary. It my have little value to you but that doesn't mean it has little value to everyone. I don't agree that compiling to multiple architectures is without difficulty and restricting yourself to only popular ones proves the point. What specific "other user-side overhead" would you be referring to? Lots of things aren't strictly necessary, that doesn't imply they're not necessary. Yes, there is a performance cost. Sometimes that cost is worth paying.
- pjmlp 4mo ago
  No you don't, because WASM is only compute, and you need exactly runtime specific code and third party frameworks for everything else as imported functions.
  - hmry 4mo ago
    That's what WASI is for
    - pjmlp 4mo ago
      And like CORBA, or POSIX, the portability does not work 100% as being sold.
- deleted 4mo ago
  [deleted]
rvz 4mo ago
Exactly. It is entirely a misconception to believe that WASM is this silver bullet on sandboxing and it is not that great security-wise I’m afraid. It is only now being inspected by researchers and attackers who have found sandbox escapes [0] (chrome 0day), out-of-bounds [1] / use-after-free [2] and many other [3] flaws [4] in WebAssembly which I also agree that it is not enough for sandboxing at all. [0] https://nvd.nist.gov/vuln/detail/CVE-2026-11645 https://nvd.nist.gov/vuln/detail/CVE-2026-11645 [1] https://bugzilla.mozilla.org/show_bug.cgi?id=2009901 https://bugzilla.mozilla.org/show_bug.cgi?id=2009901 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=2013741 https://bugzilla.mozilla.org/show_bug.cgi?id=2013741 [3] https://www.miggo.io/vulnerability-database/cve/CVE-2026-26956 https://www.miggo.io/vulnerability-database/cve/CVE-2026-269... [4] https://github.com/bytecodealliance/wasm-micro-runtime/security/advisories/GHSA-8fc8-4g25-c8m7 https://github.com/bytecodealliance/wasm-micro-runtime/secur...
- hobofan 4mo ago
  Those are not flaws in WASM itself, but in different WASM runtimes.
  - GoblinSlayer 4mo ago
    Might as well run java or flash.
    - DonHopkins 4mo ago
      But WASM is "lawnmower not included"!
- dns_snek 4mo ago
  There's no reason to believe that [0] has anything to do with WASM, [1] and [2] are runtime implementation bugs, [3] is a vulnerability in a "weak" sandboxing library VM2 - it has nothing to do with WASM as such, and [4] is another implementation bug in an experimental WASI feature of that specific runtime which is gated behind a build flag. ------ [Re: 3] https://github.com/patriksimek/vm2 https://github.com/patriksimek/vm2 > vm2 attempts to sandbox untrusted JavaScript code within the same Node.js process as your application. It does this through a complex network of Proxies that intercept and mediate every interaction between the sandbox and the host environment. > JavaScript is an extraordinarily dynamic language. Objects can be accessed through prototype chains, constructors can be reached via error objects, symbols provide protocol hooks, and async execution creates timing windows. The sheer number of ways to traverse from one object to another in JavaScript makes building an airtight in-process sandbox extremely difficult. [Re: 4] https://github.com/search?q=repo%3Abytecodealliance%2Fwasm-micro-runtime+uvwasi+language%3AMarkdown&type=code&l=Markdown https://github.com/search?q=repo%3Abytecodealliance%2Fwasm-m...

tancop 4mo ago

sandboxing native apps just gives you security. with wasm you also get a single portable binary that can run on x86 windows, arm64 linux and in your browser with zero modification. you dont need to write platform specific code or use third party frameworks.

Panzerschrek 4mo ago
> you dont need to write platform specific code You don't need to write platform-specific code if you use some cross-platform framework. For simple programs it may be enough to use only the standard library of your language of choice. > single portable binary that can run on x86 windows, arm64 linux and in your browser with zero modification It has little value. Compiling a separate binary for each OS isn't that hard, since only a handful of architectures and operating systems are actually in use. Using an abstract cross-platform binary (like WASM) in the other hand adds extra performance costs and other user-side overhead, which isn't strictly necessary.
- zcw100 4mo ago
  > You don't need to write platform-specific code if you use some cross-platform framework. For simple programs it may be enough to use only the standard library of your language of choice. That's a circular argument and "some" is doing a lot of work there. What cross-platform framework would you be referring to? > It has little value. Compiling a separate binary for each OS isn't that hard, since only a handful of architectures and operating systems are actually in use. Using an abstract cross-platform binary (like WASM) in the other hand adds extra performance costs and other user-side overhead, which isn't strictly necessary. It my have little value to you but that doesn't mean it has little value to everyone. I don't agree that compiling to multiple architectures is without difficulty and restricting yourself to only popular ones proves the point. What specific "other user-side overhead" would you be referring to? Lots of things aren't strictly necessary, that doesn't imply they're not necessary. Yes, there is a performance cost. Sometimes that cost is worth paying.
pjmlp 4mo ago
No you don't, because WASM is only compute, and you need exactly runtime specific code and third party frameworks for everything else as imported functions.
- hmry 4mo ago
  That's what WASI is for
  - pjmlp 4mo ago
    And like CORBA, or POSIX, the portability does not work 100% as being sold.
deleted 4mo ago
[deleted]

rvz 4mo ago

Exactly. It is entirely a misconception to believe that WASM is this silver bullet on sandboxing and it is not that great security-wise I’m afraid. It is only now being inspected by researchers and attackers who have found sandbox escapes [0] (chrome 0day), out-of-bounds [1] / use-after-free [2] and many other [3] flaws [4] in WebAssembly which I also agree that it is not enough for sandboxing at all. [0] https://nvd.nist.gov/vuln/detail/CVE-2026-11645 https://nvd.nist.gov/vuln/detail/CVE-2026-11645 [1] https://bugzilla.mozilla.org/show_bug.cgi?id=2009901 https://bugzilla.mozilla.org/show_bug.cgi?id=2009901 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=2013741 https://bugzilla.mozilla.org/show_bug.cgi?id=2013741 [3] https://www.miggo.io/vulnerability-database/cve/CVE-2026-26956 https://www.miggo.io/vulnerability-database/cve/CVE-2026-269... [4] https://github.com/bytecodealliance/wasm-micro-runtime/security/advisories/GHSA-8fc8-4g25-c8m7 https://github.com/bytecodealliance/wasm-micro-runtime/secur...

hobofan 4mo ago
Those are not flaws in WASM itself, but in different WASM runtimes.
- GoblinSlayer 4mo ago
  Might as well run java or flash.
  - DonHopkins 4mo ago
    But WASM is "lawnmower not included"!
dns_snek 4mo ago
There's no reason to believe that [0] has anything to do with WASM, [1] and [2] are runtime implementation bugs, [3] is a vulnerability in a "weak" sandboxing library VM2 - it has nothing to do with WASM as such, and [4] is another implementation bug in an experimental WASI feature of that specific runtime which is gated behind a build flag. ------ [Re: 3] https://github.com/patriksimek/vm2 https://github.com/patriksimek/vm2 > vm2 attempts to sandbox untrusted JavaScript code within the same Node.js process as your application. It does this through a complex network of Proxies that intercept and mediate every interaction between the sandbox and the host environment. > JavaScript is an extraordinarily dynamic language. Objects can be accessed through prototype chains, constructors can be reached via error objects, symbols provide protocol hooks, and async execution creates timing windows. The sheer number of ways to traverse from one object to another in JavaScript makes building an airtight in-process sandbox extremely difficult. [Re: 4] https://github.com/search?q=repo%3Abytecodealliance%2Fwasm-micro-runtime+uvwasi+language%3AMarkdown&type=code&l=Markdown https://github.com/search?q=repo%3Abytecodealliance%2Fwasm-m...