7 ms·

This sounds like ActiveX. Security issues related to ActiveX are solved or not? Because if they are not, then it's just a reskin of ActiveX and malware authors

This sounds like ActiveX. Security issues related to ActiveX are solved or not? Because if they are not, then it's just a reskin of ActiveX and malware authors gonna have a field day.

apignotti 5y ago
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
That is the thing with fake security advertising of WebAssembly. You can just as easily compile heartbleed into WebAssembly and call it a day. Yes it is sandboxed, but hardly any different than running an OS process with sandboxing lock down regarding which OS syscalls are allowed. Think it this way, just because an OS container cannot exploit its host (minus hypervisor bugs), that doesn't mean that what is inside isn't subject to security flaws.
- the_duke 5y ago
  You keep repeating this, but it's simply not true. The syscall surface is zero by default. WASI of course expands that by a lot, but sane WASI implementations require restrictive whitelisting of available resources like specific files or directories that can be accessed. (wasmtime-wasi does this well,for example). The whole wasi spec is aiming for capability based security, including things like only providing access to pre-opened sockets. All production deployments of server side Wasm I have seen have very tight scoping. Sandboxing on Linux, in contrast, is a complicated mess, with a myriad of partial and leaky solutions (SELinux, Apparmor, Docker, Snap, Flatpak, ...) . Having a good cross platform toolkit is completely out of reach. The only OS that has comparable sandboxing that is practical is Fuchsia.
  - pjmlp 5y ago
    And will keep repeating ad eternum given the fake security sales from Webassembly, for God's sake evem the standard has a security section mentioning possible issues not addressed. There is no magic in WASM, only when the only thing it does is warming up a CPU.
    - the_duke 5y ago
      I'm happy to have a technical discussion, but your comments always stop at "Wasm bad", without countering the arguments.
      - kaba0 5y ago
jchw 5y ago
HN is doing its typical “well, technically,” thing in the replies here, so I’ll give a better answer: Yes, the problems that plagued ActiveX are gone now. WebAssembly hosts still have vulnerabilities from time to time, but they are not literally by-design like they were with ActiveX. They’re typically complicated and to do similar things to what ActiveX modules could do completely ordinarily would require breaking many sandbox layers. The discussion also is breaking into an unrelated branch about security within WebAssembly, so it’s worth pointing out that the security model of WebAssembly is that it should prevent the host machine from being attacked by code running in the sandbox, not that it makes code running in the sandbox any more secure. It doesn’t make code in the sandbox not susceptible to most classes of errors, it just isolates those errors to runtime errors and not exploitable bugs that can escalate privilege. ActiveX, of course, did not deal with either security model, instead shrugging it off and just assuming that code signing would be a good enough deterrent to malware. (Of course, the problem with this is manyfold, including the fact that just because a module is trustworthy and not malicious, does not mean it should be exposed to all users, and the fact that even if you trust the company behind the module, that doesn’t make the module any more guaranteed to be secure.)

This sounds like ActiveX. Security issues related to ActiveX are solved or not? Because if they are not, then it's just a reskin of ActiveX and malware authors gonna have a field day.

apignotti 5y ago

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

That is the thing with fake security advertising of WebAssembly. You can just as easily compile heartbleed into WebAssembly and call it a day. Yes it is sandboxed, but hardly any different than running an OS process with sandboxing lock down regarding which OS syscalls are allowed. Think it this way, just because an OS container cannot exploit its host (minus hypervisor bugs), that doesn't mean that what is inside isn't subject to security flaws.

the_duke 5y ago
You keep repeating this, but it's simply not true. The syscall surface is zero by default. WASI of course expands that by a lot, but sane WASI implementations require restrictive whitelisting of available resources like specific files or directories that can be accessed. (wasmtime-wasi does this well,for example). The whole wasi spec is aiming for capability based security, including things like only providing access to pre-opened sockets. All production deployments of server side Wasm I have seen have very tight scoping. Sandboxing on Linux, in contrast, is a complicated mess, with a myriad of partial and leaky solutions (SELinux, Apparmor, Docker, Snap, Flatpak, ...) . Having a good cross platform toolkit is completely out of reach. The only OS that has comparable sandboxing that is practical is Fuchsia.
- pjmlp 5y ago
  And will keep repeating ad eternum given the fake security sales from Webassembly, for God's sake evem the standard has a security section mentioning possible issues not addressed. There is no magic in WASM, only when the only thing it does is warming up a CPU.
  - the_duke 5y ago
    I'm happy to have a technical discussion, but your comments always stop at "Wasm bad", without countering the arguments.
    - kaba0 5y ago

jchw 5y ago

HN is doing its typical “well, technically,” thing in the replies here, so I’ll give a better answer: Yes, the problems that plagued ActiveX are gone now. WebAssembly hosts still have vulnerabilities from time to time, but they are not literally by-design like they were with ActiveX. They’re typically complicated and to do similar things to what ActiveX modules could do completely ordinarily would require breaking many sandbox layers. The discussion also is breaking into an unrelated branch about security within WebAssembly, so it’s worth pointing out that the security model of WebAssembly is that it should prevent the host machine from being attacked by code running in the sandbox, not that it makes code running in the sandbox any more secure. It doesn’t make code in the sandbox not susceptible to most classes of errors, it just isolates those errors to runtime errors and not exploitable bugs that can escalate privilege. ActiveX, of course, did not deal with either security model, instead shrugging it off and just assuming that code signing would be a good enough deterrent to malware. (Of course, the problem with this is manyfold, including the fact that just because a module is trustworthy and not malicious, does not mean it should be exposed to all users, and the fact that even if you trust the company behind the module, that doesn’t make the module any more guaranteed to be secure.)