3 ms·

I know that there are existing bytecodes. I'm asking what you think WebAssembly should have learned from them but didn't. But based on your response I'm guessin

by mort96 3y ago

I know that there are existing bytecodes. I'm asking what you think WebAssembly should have learned from them but didn't. But based on your response I'm guessing you don't really have that kind of thoughtful critique of WebAssembly?

pjmlp 3y ago
Here is one, despite all the security marketing, programs inside the sandbox can still be tricked into internal memory corruption, as there is no way to prevent bounds checking inside the same linear memory segment. So they are bound to black box attacks, where a clever sequence of function calls can eventually result in something being allowed that wasn't before, as the internal memory state of the WASM module is now corrupt.
- CyberDildonics 3y ago
  You have no sources or evidence for these claims because they aren't true.
  - pjmlp 3y ago
    "Everything Old is New Again: Binary Security of WebAssembly" https://www.usenix.org/conference/usenixsecurity20/presentation/lehmann https://www.usenix.org/conference/usenixsecurity20/presentat... One of many security presentations, finding the others is an exercise for the reader that actually cares about security.
    - CyberDildonics 3y ago
      This doesn't say what you're claiming. It just says that webasm stack frames are next to each other like C. A C program that crashes will crash in webasm.
      - pjmlp 3y ago
        Thanks for confirming not having any clue in Infosec.
        CyberDildonics 3y ago
        Explain specifically and technically what you think the problem is. You can't overrun buffers and overflow stacks in any language without it crashing. There is also no expectation that data in one buffer in webasm would be separate from another buffer.
        mort96 3y ago
        You should stop arguing. He's correct in this critique, and you don't even disagree that he's correct. The problem is that it's a critique of how (he alleges) hype/VC people have over-sold WASM, not an actual problem with WASM.
        CyberDildonics 3y ago
        You should stop arguing, because the claim of insecurity is not being backed up by anything. Show me an exploit, show me with detailed and technical information, show some sort of evidence. Both of you are just repeating your claim more forcefully, never adding anything that backs up your claims. Compiling C to webasm doesn't fix C bugs within the local memory space of webasm? No one has those expectations except people with a bizarre vendetta against a simple and benign technology like webasm.
        mort96 3y ago
        pjmlp's claim is: there are people out there who over-hype WASM, who claim that simply compiling a C program to WASM will automatically make it secure. pjmlp is claiming that these over-hyped claims are wrong (in their words: "programs inside the sandbox can still be tricked into internal memory corruption"). You agree that those over-hyped claims are wrong (in your own words: "compiling C to webasm doesn't fix C bugs within the local memory space of webasm"). I agree that those over-hyped claims are wrong. If one wants to argue against pjmlp (as you and I both do), there are two ways to go: 1) you can say that nobody is making those claims, or 2) you can say that if people are making those claims, the problem is with those people, not WASM. I choose #2, because it seems plausible to me that VC-backed startup types over-hype WASM. If I was more familiar with the discourse around WASM, I might try to argue #1 if I thought I could demonstrate that over-hyping WASM doesn't really happen. Maybe you could go the burden of proof route, that it's their responsibility to prove that people are over-hyping WASM and take the discussion from there. But you ... don't seem to be engaging with the argument. You agree that "compiling C to wasm doesn't fix C bugs within the local memory space of wasm", yet you say that "the claim of insecurity is not being backed up by anything" when the claim of insecurity is that compiling C to wasm doesn't fix C bugs within the local memory space of wasm. That's literally what was meant by "internal memory corruption" in pjmlp's very first comment which mentioned the security angle. Again, they're wrong to mention this as a flaw of WASM because making C code resistant against "internal memory corruption" was never a goal of WASM, but that doesn't mean that their "claim of insecurity" is wrong. To show an example of the kind of exploit pjmlp is talking about, just take any C program with some kind of exploitable buffer overflow, run it in wasmtime or wasmer or whatever, and exploit the buffer overflow. Maybe the buffer overflow lets an attacker write 101 bytes to a 100 byte buffer and therefore flip an "isAdministrator" flag from 0 to 1. You, I and pjmlp all agree that such security issues can exist; WASM doesn't magically protect C code from memory corruption. And that is not a flaw in WASM, which is what your argument should be focusing on.
- mort96 3y ago
  This is correct, and it's something people who use WASM for security need to be aware of. My program can use WASM to execute untrusted user-supplied code (such as web pages) safely, but compiling my application to WASM and running it in a sandboxed VM doesn't protect me from security bugs in my own code. Is this an example of WASM not learning from other bytecodes though? 1) Has other bytecodes fixed it? It's not like compiling your C application to CLR protects you from internal memory corruption bugs either, right? And 2) Was protecting against internal memory corruption even a goal? To me it always seemed like the purpose of WASM is to be a cross platform way to run untrusted code sandboxed, just like JS but faster and more appropriate as a compilation target; and whether you compile to WASM or JS, your C program might have memory corruption bugs. If you're only complaining about the VC-funded hype machine, I could probably be convinced that WASM is sold as something it isn't. I haven't seen it myself really but it's exactly what those sorts of people are wont to do. But that's surely a critique of the hype machine, not of WASM failing to learn from other bytecode designs, no?

by mort96 3y ago

pjmlp 3y ago

Here is one, despite all the security marketing, programs inside the sandbox can still be tricked into internal memory corruption, as there is no way to prevent bounds checking inside the same linear memory segment. So they are bound to black box attacks, where a clever sequence of function calls can eventually result in something being allowed that wasn't before, as the internal memory state of the WASM module is now corrupt.

CyberDildonics 3y ago
You have no sources or evidence for these claims because they aren't true.
- pjmlp 3y ago
  "Everything Old is New Again: Binary Security of WebAssembly" https://www.usenix.org/conference/usenixsecurity20/presentation/lehmann https://www.usenix.org/conference/usenixsecurity20/presentat... One of many security presentations, finding the others is an exercise for the reader that actually cares about security.
  - CyberDildonics 3y ago
    This doesn't say what you're claiming. It just says that webasm stack frames are next to each other like C. A C program that crashes will crash in webasm.
    - pjmlp 3y ago
      Thanks for confirming not having any clue in Infosec.
      - CyberDildonics 3y ago
        Explain specifically and technically what you think the problem is. You can't overrun buffers and overflow stacks in any language without it crashing. There is also no expectation that data in one buffer in webasm would be separate from another buffer.
        mort96 3y ago
        You should stop arguing. He's correct in this critique, and you don't even disagree that he's correct. The problem is that it's a critique of how (he alleges) hype/VC people have over-sold WASM, not an actual problem with WASM.
        CyberDildonics 3y ago
        You should stop arguing, because the claim of insecurity is not being backed up by anything. Show me an exploit, show me with detailed and technical information, show some sort of evidence. Both of you are just repeating your claim more forcefully, never adding anything that backs up your claims. Compiling C to webasm doesn't fix C bugs within the local memory space of webasm? No one has those expectations except people with a bizarre vendetta against a simple and benign technology like webasm.
        mort96 3y ago
        pjmlp's claim is: there are people out there who over-hype WASM, who claim that simply compiling a C program to WASM will automatically make it secure. pjmlp is claiming that these over-hyped claims are wrong (in their words: "programs inside the sandbox can still be tricked into internal memory corruption"). You agree that those over-hyped claims are wrong (in your own words: "compiling C to webasm doesn't fix C bugs within the local memory space of webasm"). I agree that those over-hyped claims are wrong. If one wants to argue against pjmlp (as you and I both do), there are two ways to go: 1) you can say that nobody is making those claims, or 2) you can say that if people are making those claims, the problem is with those people, not WASM. I choose #2, because it seems plausible to me that VC-backed startup types over-hype WASM. If I was more familiar with the discourse around WASM, I might try to argue #1 if I thought I could demonstrate that over-hyping WASM doesn't really happen. Maybe you could go the burden of proof route, that it's their responsibility to prove that people are over-hyping WASM and take the discussion from there. But you ... don't seem to be engaging with the argument. You agree that "compiling C to wasm doesn't fix C bugs within the local memory space of wasm", yet you say that "the claim of insecurity is not being backed up by anything" when the claim of insecurity is that compiling C to wasm doesn't fix C bugs within the local memory space of wasm. That's literally what was meant by "internal memory corruption" in pjmlp's very first comment which mentioned the security angle. Again, they're wrong to mention this as a flaw of WASM because making C code resistant against "internal memory corruption" was never a goal of WASM, but that doesn't mean that their "claim of insecurity" is wrong. To show an example of the kind of exploit pjmlp is talking about, just take any C program with some kind of exploitable buffer overflow, run it in wasmtime or wasmer or whatever, and exploit the buffer overflow. Maybe the buffer overflow lets an attacker write 101 bytes to a 100 byte buffer and therefore flip an "isAdministrator" flag from 0 to 1. You, I and pjmlp all agree that such security issues can exist; WASM doesn't magically protect C code from memory corruption. And that is not a flaw in WASM, which is what your argument should be focusing on.
mort96 3y ago
This is correct, and it's something people who use WASM for security need to be aware of. My program can use WASM to execute untrusted user-supplied code (such as web pages) safely, but compiling my application to WASM and running it in a sandboxed VM doesn't protect me from security bugs in my own code. Is this an example of WASM not learning from other bytecodes though? 1) Has other bytecodes fixed it? It's not like compiling your C application to CLR protects you from internal memory corruption bugs either, right? And 2) Was protecting against internal memory corruption even a goal? To me it always seemed like the purpose of WASM is to be a cross platform way to run untrusted code sandboxed, just like JS but faster and more appropriate as a compilation target; and whether you compile to WASM or JS, your C program might have memory corruption bugs. If you're only complaining about the VC-funded hype machine, I could probably be convinced that WASM is sold as something it isn't. I haven't seen it myself really but it's exactly what those sorts of people are wont to do. But that's surely a critique of the hype machine, not of WASM failing to learn from other bytecode designs, no?