8 ms·

There is a very big difference: ActiveX was native code that was literally running on your system with full access to system calls. CheerpX is a Virtual Machin

There is a very big difference: ActiveX was native code that was literally running on your system with full access to system calls. CheerpX is a Virtual Machine environment, it JIT compiles Wasm code from x86 binaries and it is fully sandboxed by the browser. It _cannot_ access your system even if it tried.

pjmlp 5y ago
It can still be exploited the Applets/Flash way, by forcing the internal memory to become corrupted and with it change its behaviour.
- nynx 5y ago
  It literally cannot.
  - pjmlp 5y ago
    I advise some courses in pentesting.
  - codr7 5y ago
    Assuming the VM can't be exploited/escaped somehow, which would be a first.
- sfink 5y ago
  Right, you can corrupt memory and thereby alter behavior, but that memory is a managed array. You can't corrupt anything outside of the application's own memory. As you say, you can change behavior, and thereby do whatever you want with whatever the wasm application is allowed to access. Which is a very limited set of things. Likening it to Java applets or Flash is deceptive -- yes, you can still hack them and exploit vulnerabilities. But the scope of what you can do with such vulnerabilities is wildly, dramatically different. Even when sandboxed, Flash has an enormously wider attack surface to play with. WebAssembly has barely anything. It's like the difference between patching a leak in your roof with a sponge vs tar paper. In theory, water could find a path through the tar paper.
  - pjmlp 5y ago
    Imagine a WASM module used to control security authentication in the browser, or controlling IoT devices in a factory, now that it is fashionable to run WASM outside of the browser.
    - sfink 5y ago
      Right, I agree that wasm being used to control nuclear launches is not fundamentally better than native sandboxed C++ code in terms of preventing unwanted nuclear launches. But wasm being used to control the brightness pattern of a blinky light on the console of the machine that controls nuclear launches? That is fundamentally safer than native sandboxed C++ code being used to control the blinky light. I'm guessing we don't actually disagree on anything here -- I also feel like people are making unwarranted assumptions that wasm gives you more safety than it actually does. (It reminds me of another incorrect assumption that seems to get made a lot, that running unsafe code in a VM means you don't need to worry that it'll escape to the host or other VMs on that host.)
      - pjmlp 5y ago
        Yes, it is those unwarranted assumptions that irk me, as then you see talks how everything is "magical" with WASM, when it is just yet another bytecode format.
        MaxBarraclough 5y ago
        Right, the only 'magical' thing about WASM is that it has browser support. On the plus side, browsers have a comparatively good track-record as secure sandboxes. Far better than the JVM, say.
      - MaxBarraclough 5y ago
        > But wasm being used to control the brightness pattern of a blinky light on the console of the machine that controls nuclear launches? That is fundamentally safer than native sandboxed C++ code being used to control the blinky light. How so? There are established techniques for developing safety-critical software, and they don't tend to rely on the assumption that a sophisticated JIT compiler is free of bugs. Or do you mean untrusted code for controlling the blinky light?
- MikeHolman 5y ago
  Wasm has the same security risk as executing JavaScript in your browser, except with less risk of XSS type security issues because wasm modules are better encapsulated.
runeks 5y ago
> It _cannot_ access your system even if it tried. That’s the intent, at least. I’m sure we’ll get to see exploits that manage to do exactly this.
- comex 5y ago
  Perhaps, but if so, that would be a bug in the browser’s WebAssembly implementation, not CheerpX.
  - jfoutz 5y ago
    CheerpX looks amazing. Not blaming that project it in any way. But rowhammer is still a thing. There's a whole stack of abstractions, that all _may be_ vulnerable. I'm sure CheerpX is very good, but there's no way to _know_ that all the dependencies from the toolchain used to build all the way down to the running environment is actually bug free. As a first line of investigation, I'd suspect cheerpX, just because so many eyes look at browser sandboxes. _shrug_ your milage may vary.
    - saagarjha 5y ago
      You can Rowhammer from JavaScript already, so this really has nothing to do with CheerpX.
      - jfoutz 5y ago
        Very true. Let me try to restate. I don't know how to prove the absence of a thing. I can only prove existence. I was trying to highlight that every layer of abstraction has vulnerabilities all the way down to the hardware level. I'm perfectly willing to accept that CheerpX has no known vulnerabilities.
        jerry1979 5y ago
        It may have more to do with the idea that since CheerpX runs in the browser, the threat model of CheerpX is the same as the thread model of using your web browser to browse any other site.

pjmlp 5y ago

It can still be exploited the Applets/Flash way, by forcing the internal memory to become corrupted and with it change its behaviour.

nynx 5y ago
It literally cannot.
- pjmlp 5y ago
  I advise some courses in pentesting.
- codr7 5y ago
  Assuming the VM can't be exploited/escaped somehow, which would be a first.
sfink 5y ago
Right, you can corrupt memory and thereby alter behavior, but that memory is a managed array. You can't corrupt anything outside of the application's own memory. As you say, you can change behavior, and thereby do whatever you want with whatever the wasm application is allowed to access. Which is a very limited set of things. Likening it to Java applets or Flash is deceptive -- yes, you can still hack them and exploit vulnerabilities. But the scope of what you can do with such vulnerabilities is wildly, dramatically different. Even when sandboxed, Flash has an enormously wider attack surface to play with. WebAssembly has barely anything. It's like the difference between patching a leak in your roof with a sponge vs tar paper. In theory, water could find a path through the tar paper.
- pjmlp 5y ago
  Imagine a WASM module used to control security authentication in the browser, or controlling IoT devices in a factory, now that it is fashionable to run WASM outside of the browser.
  - sfink 5y ago
    Right, I agree that wasm being used to control nuclear launches is not fundamentally better than native sandboxed C++ code in terms of preventing unwanted nuclear launches. But wasm being used to control the brightness pattern of a blinky light on the console of the machine that controls nuclear launches? That is fundamentally safer than native sandboxed C++ code being used to control the blinky light. I'm guessing we don't actually disagree on anything here -- I also feel like people are making unwarranted assumptions that wasm gives you more safety than it actually does. (It reminds me of another incorrect assumption that seems to get made a lot, that running unsafe code in a VM means you don't need to worry that it'll escape to the host or other VMs on that host.)
    - pjmlp 5y ago
      Yes, it is those unwarranted assumptions that irk me, as then you see talks how everything is "magical" with WASM, when it is just yet another bytecode format.
      - MaxBarraclough 5y ago
        Right, the only 'magical' thing about WASM is that it has browser support. On the plus side, browsers have a comparatively good track-record as secure sandboxes. Far better than the JVM, say.
    - MaxBarraclough 5y ago
      > But wasm being used to control the brightness pattern of a blinky light on the console of the machine that controls nuclear launches? That is fundamentally safer than native sandboxed C++ code being used to control the blinky light. How so? There are established techniques for developing safety-critical software, and they don't tend to rely on the assumption that a sophisticated JIT compiler is free of bugs. Or do you mean untrusted code for controlling the blinky light?
MikeHolman 5y ago
Wasm has the same security risk as executing JavaScript in your browser, except with less risk of XSS type security issues because wasm modules are better encapsulated.

runeks 5y ago

> It _cannot_ access your system even if it tried. That’s the intent, at least. I’m sure we’ll get to see exploits that manage to do exactly this.

comex 5y ago
Perhaps, but if so, that would be a bug in the browser’s WebAssembly implementation, not CheerpX.
- jfoutz 5y ago
  CheerpX looks amazing. Not blaming that project it in any way. But rowhammer is still a thing. There's a whole stack of abstractions, that all _may be_ vulnerable. I'm sure CheerpX is very good, but there's no way to _know_ that all the dependencies from the toolchain used to build all the way down to the running environment is actually bug free. As a first line of investigation, I'd suspect cheerpX, just because so many eyes look at browser sandboxes. _shrug_ your milage may vary.
  - saagarjha 5y ago
    You can Rowhammer from JavaScript already, so this really has nothing to do with CheerpX.
    - jfoutz 5y ago
      Very true. Let me try to restate. I don't know how to prove the absence of a thing. I can only prove existence. I was trying to highlight that every layer of abstraction has vulnerabilities all the way down to the hardware level. I'm perfectly willing to accept that CheerpX has no known vulnerabilities.
      - jerry1979 5y ago
        It may have more to do with the idea that since CheerpX runs in the browser, the threat model of CheerpX is the same as the thread model of using your web browser to browse any other site.