4 ms·

Can you link to an example of this exploit? Does javascript suffer from the same problem?

pjmlp 7y ago
Any kind of typical C memory corruption that you can think of that fails to validate the buffer sizes that you give as parameters. WebAssembly memory access bytecodes only do bounds checking of the linear memory block that gets allocated to the module. You then do your own memory management taking subsets from that memory block and assigning it to the respective internal heap allocations or global memory blocks. So you just need to have a couple of structs or C string/arrays, living alongside each other and overwrite one of them by writing too much data due to miscalculations of the memory segment holding the data.
- BubRoss 7y ago
  Wouldn't that just corrupt your own program? If there is a security flaw you could demonstrate it.
  - pjmlp 7y ago
    Except that you load code from multiple sources and one could eventually have a piece of JavaScript code that makes use of such behaviour to have access to some feature that by default is not accessible. I rather let WebAssembly turn out to be the next Flash, when black hats start looking at it with the same care they had before, no need to waste cycles myself, as it is a lost battle against WebAssembly advocacy.
    - maoeurk 7y ago
      > Except that you load code from multiple sources and one could eventually have a piece of JavaScript code that makes use of such behaviour to have access to some feature that by default is not accessible. With all due respect, that doesn't make WebAssembly unsafe in any way. By the same logic, any program that takes any kind of user input is unsafe because the program could trust data it should not trust and then execute incorrectly. If a program does not validate (untrusted) input then it is the program's fault. Not the input's fault or the input-producing-method's fault. I agree with where you're coming from though. People are going to make mistakes and if the average developer has to interpret blobs of bits as meaningful data structures just to get things done, then we are going to see a lot of these types of problems. However, there are already projects in the works that are automating the $LANGUAGE to Wasm glue code which should completely mitigate this issue.
    - deleted 7y ago
      [deleted]
    - BubRoss 7y ago
      I don't understand what you mean by "a piece of JavaScript code that makes use of such behaviour". Webasm is accessed by javascript, not the other way around. This really sounds like you have an axe to grind with webasm for some reason, the things you saying seems like grasping at straws. It already works in browsers, so if there is something to exploit you could demonstrate it with a few files on github.
      - pjmlp 7y ago
        Yep, overselling security. I guess everyone knows how to corrupt memory with C code, no need for github files.
        BubRoss 7y ago
        Are you saying webasm will crash or that it is insecure? These are two different things and you seem to be conflating them. In your posts you have said that it is insecure but when you talk about specifics it just seems to be about crashing. Then when pressed you avoid any examples.
        pjmlp 7y ago
        I keep telling the examples, memory corruption, typical C exploits. Apparently the force is strong with WebAssembly advocacy.
        BubRoss 7y ago
        I meant working examples. Saying "it's insecure!" and then calling your own words evidence doesn't count. If there are actual exploits or security flaws, then demonstrate them with a working implementation. You seem to be trying to turn a technical discussion into an emotional one.
        pjmlp 7y ago
        If you want code examples, just go to the CVE database and compile any memory corruption related to C into a WebAssembly module. Why should I need to provide new examples when we have plenty to chose from?

Any kind of typical C memory corruption that you can think of that fails to validate the buffer sizes that you give as parameters. WebAssembly memory access bytecodes only do bounds checking of the linear memory block that gets allocated to the module. You then do your own memory management taking subsets from that memory block and assigning it to the respective internal heap allocations or global memory blocks. So you just need to have a couple of structs or C string/arrays, living alongside each other and overwrite one of them by writing too much data due to miscalculations of the memory segment holding the data.

BubRoss 7y ago
Wouldn't that just corrupt your own program? If there is a security flaw you could demonstrate it.
- pjmlp 7y ago
  Except that you load code from multiple sources and one could eventually have a piece of JavaScript code that makes use of such behaviour to have access to some feature that by default is not accessible. I rather let WebAssembly turn out to be the next Flash, when black hats start looking at it with the same care they had before, no need to waste cycles myself, as it is a lost battle against WebAssembly advocacy.
  - maoeurk 7y ago
    > Except that you load code from multiple sources and one could eventually have a piece of JavaScript code that makes use of such behaviour to have access to some feature that by default is not accessible. With all due respect, that doesn't make WebAssembly unsafe in any way. By the same logic, any program that takes any kind of user input is unsafe because the program could trust data it should not trust and then execute incorrectly. If a program does not validate (untrusted) input then it is the program's fault. Not the input's fault or the input-producing-method's fault. I agree with where you're coming from though. People are going to make mistakes and if the average developer has to interpret blobs of bits as meaningful data structures just to get things done, then we are going to see a lot of these types of problems. However, there are already projects in the works that are automating the $LANGUAGE to Wasm glue code which should completely mitigate this issue.
  - deleted 7y ago
    [deleted]
  - BubRoss 7y ago
    I don't understand what you mean by "a piece of JavaScript code that makes use of such behaviour". Webasm is accessed by javascript, not the other way around. This really sounds like you have an axe to grind with webasm for some reason, the things you saying seems like grasping at straws. It already works in browsers, so if there is something to exploit you could demonstrate it with a few files on github.
    - pjmlp 7y ago
      Yep, overselling security. I guess everyone knows how to corrupt memory with C code, no need for github files.
      - BubRoss 7y ago
        Are you saying webasm will crash or that it is insecure? These are two different things and you seem to be conflating them. In your posts you have said that it is insecure but when you talk about specifics it just seems to be about crashing. Then when pressed you avoid any examples.
        pjmlp 7y ago
        I keep telling the examples, memory corruption, typical C exploits. Apparently the force is strong with WebAssembly advocacy.
        BubRoss 7y ago
        I meant working examples. Saying "it's insecure!" and then calling your own words evidence doesn't count. If there are actual exploits or security flaws, then demonstrate them with a working implementation. You seem to be trying to turn a technical discussion into an emotional one.
        pjmlp 7y ago
        If you want code examples, just go to the CVE database and compile any memory corruption related to C into a WebAssembly module. Why should I need to provide new examples when we have plenty to chose from?