4 ms·

If you are porting anything from C into WebAssembly, keep in mind that you still inherit C based vulnerabilities. [0] [1] [0] https://soft.vub.ac.be/Publicati

by rvz 5mo ago

If you are porting anything from C into WebAssembly, keep in mind that you still inherit C based vulnerabilities. [0] [1] [0] https://soft.vub.ac.be/Publications/2022/vub-tr-soft-22-02.pdf https://soft.vub.ac.be/Publications/2022/vub-tr-soft-22-02.p... [1] https://www.usenix.org/system/files/sec20-lehmann.pdf https://www.usenix.org/system/files/sec20-lehmann.pdf

pjmlp 5mo ago
No worries, it is sandboxed. /s
- yjftsjthsd-h 5mo ago
  Why /s? That does massively reduce the exposure
  - pjmlp 5mo ago
    As much as an OS process, on a modern OS that is. The bounds checking story is only on the external limits of linear memory segments. If memory gets corrupted inside a linear memory segment, it can equally well be exploited to change execution behaviour, which for many scenarios is already good enough for the attacker. Yet these kind of attack vectors usually are dropped from blog posts selling WebAssembly as a revolutionary bytecode. It is only yet another one since various others that came and went since UNCOL became an idea.
    - koolala 5mo ago
      How could any general execution environment guarantee memory like that? That doesn't seem like a realistic expectation. You can write safe Rust code if you want memory guarantees in WASM but would you really want it to block the ability to run unsafe Rust code too?
      - pjmlp 5mo ago
        Easy, see other bytecodes with bounds checking opcodes, and where use of unsafe bytecodes taint the executable on the verifier, which then requires explicit execution permission.
        koolala 5mo ago
        Taint it how? What kind of permissions? Your fix is a pop up warning on unsafe code?
        pjmlp 5mo ago
        See, this is where knowing the history of bytecode formats since UNCOL, would be relevant. Burroungs (1961), https://en.wikipedia.org/wiki/Burroughs_Large_Systems https://en.wikipedia.org/wiki/Burroughs_Large_Systems "In fact, all unsafe constructs are rejected by the NEWP compiler unless a block is specifically marked to allow those instructions. Such marking of blocks provide a multi-level protection mechanism." "NEWP programs that contain unsafe constructs are initially non-executable. The security administrator of a system is able to "bless" such programs and make them executable, but normal users are not able to do this. (Even "privileged users", who normally have essentially root privilege, may be unable to do this depending on the configuration chosen by the site.) While NEWP can be used to write general programs and has a number of features designed for large software projects, it does not support everything ALGOL does." CLR (2001) https://learn.microsoft.com/en-us/dotnet/framework/tools/peverify-exe-peverify-tool https://learn.microsoft.com/en-us/dotnet/framework/tools/pev... "Normally, code that is not verifiably type safe cannot run, although you can set security policy to allow the execution of trusted but unverifiable code." IBM i (nee AS/400) https://medium.com/@dhemanthc/ibm-i-architecture-how-timi-and-slic-enable-hardware-independence-82aea3f2dae3 https://medium.com/@dhemanthc/ibm-i-architecture-how-timi-an... "SLIC enforces IBM i’s unique object-based model. Rather than managing raw memory locations or file descriptors, all resources (programs, files, queues, data areas, libraries) are managed as named objects with properties, ownership, and permissions. This object model permeates everything in IBM i, from file systems to program calls." Aka capabilities, and what CHERI project is pushing for as means to fix C and C++ code at hardware level.
koolala 5mo ago
which of these vulnerabilities are most concerning to you in wasm programs?
- rvz 5mo ago
  All of them.
  - koolala 5mo ago
    Can you explain why atleast one of them is bad in WASM in your own words? Why be concerned? There are not really that many capabilities inside the WASM program that can be exploited and its hard to imagine a realistic example. An example that paper gave is doing document.write from WASM with unsantized strings but that is bad practice even in Javascript.
jedisct1 5mo ago
Also https://00f.net/2018/11/25/webassembly-doesnt-make-unsafe-languages-safe/ https://00f.net/2018/11/25/webassembly-doesnt-make-unsafe-la...

by rvz 5mo ago

pjmlp 5mo ago

No worries, it is sandboxed. /s

yjftsjthsd-h 5mo ago
Why /s? That does massively reduce the exposure
- pjmlp 5mo ago
  As much as an OS process, on a modern OS that is. The bounds checking story is only on the external limits of linear memory segments. If memory gets corrupted inside a linear memory segment, it can equally well be exploited to change execution behaviour, which for many scenarios is already good enough for the attacker. Yet these kind of attack vectors usually are dropped from blog posts selling WebAssembly as a revolutionary bytecode. It is only yet another one since various others that came and went since UNCOL became an idea.
  - koolala 5mo ago
    How could any general execution environment guarantee memory like that? That doesn't seem like a realistic expectation. You can write safe Rust code if you want memory guarantees in WASM but would you really want it to block the ability to run unsafe Rust code too?
    - pjmlp 5mo ago
      Easy, see other bytecodes with bounds checking opcodes, and where use of unsafe bytecodes taint the executable on the verifier, which then requires explicit execution permission.
      - koolala 5mo ago
        Taint it how? What kind of permissions? Your fix is a pop up warning on unsafe code?
        pjmlp 5mo ago
        See, this is where knowing the history of bytecode formats since UNCOL, would be relevant. Burroungs (1961), https://en.wikipedia.org/wiki/Burroughs_Large_Systems https://en.wikipedia.org/wiki/Burroughs_Large_Systems "In fact, all unsafe constructs are rejected by the NEWP compiler unless a block is specifically marked to allow those instructions. Such marking of blocks provide a multi-level protection mechanism." "NEWP programs that contain unsafe constructs are initially non-executable. The security administrator of a system is able to "bless" such programs and make them executable, but normal users are not able to do this. (Even "privileged users", who normally have essentially root privilege, may be unable to do this depending on the configuration chosen by the site.) While NEWP can be used to write general programs and has a number of features designed for large software projects, it does not support everything ALGOL does." CLR (2001) https://learn.microsoft.com/en-us/dotnet/framework/tools/peverify-exe-peverify-tool https://learn.microsoft.com/en-us/dotnet/framework/tools/pev... "Normally, code that is not verifiably type safe cannot run, although you can set security policy to allow the execution of trusted but unverifiable code." IBM i (nee AS/400) https://medium.com/@dhemanthc/ibm-i-architecture-how-timi-and-slic-enable-hardware-independence-82aea3f2dae3 https://medium.com/@dhemanthc/ibm-i-architecture-how-timi-an... "SLIC enforces IBM i’s unique object-based model. Rather than managing raw memory locations or file descriptors, all resources (programs, files, queues, data areas, libraries) are managed as named objects with properties, ownership, and permissions. This object model permeates everything in IBM i, from file systems to program calls." Aka capabilities, and what CHERI project is pushing for as means to fix C and C++ code at hardware level.

koolala 5mo ago

which of these vulnerabilities are most concerning to you in wasm programs?

rvz 5mo ago
All of them.
- koolala 5mo ago
  Can you explain why atleast one of them is bad in WASM in your own words? Why be concerned? There are not really that many capabilities inside the WASM program that can be exploited and its hard to imagine a realistic example. An example that paper gave is doing document.write from WASM with unsantized strings but that is bad practice even in Javascript.

jedisct1 5mo ago

Also https://00f.net/2018/11/25/webassembly-doesnt-make-unsafe-languages-safe/ https://00f.net/2018/11/25/webassembly-doesnt-make-unsafe-la...