5 ms·

I'd expect server-side JS code running on popular VM (v8, spidermonkey) to be safer than custom C++ (sandboxed vs running on the bare os). And BTW, this is why

I'd expect server-side JS code running on popular VM (v8, spidermonkey) to be safer than custom C++ (sandboxed vs running on the bare os). And BTW, this is why WebAssembly runtime on the server is a big deal. Being able to painlessly run any untrusted code from "nonsafe language" in a sandboxed environment. Also, if you read it correctly, Avast is running "wild" Javascript in a custom privileged VM (potentially written in C++)

LeoNatan25 7y ago
Your expectation makes no sense. Popular JS VMs have huge attack surfaces, and are prime candidates for gray and black market vulnerability hunts. They are often not maintained, thus once a vulnerability is discovered, the entire app is compromised. In the case of a highly-privileged process, this can be catastrophic. Contrast this with tailor-made, slim and well tested C++ code. And yes, I do expect security companies to have well-written and well-tested code.
- paraboul 7y ago
  Can I invoke my @pcwalton card here? :-)
- deleted 7y ago
  [deleted]
- detaro 7y ago
  > And yes, I do expect security companies to have well-written and well-tested code. Your expectation makes no sense, given the vulnerabilities we've seen in AV software in the past decade. If they insist that executing suspect JS is a good idea, they a) probably should use an established interpreter unless there's good reasons not to and b) not run it privileged. EDIT: Avast appears to have deactivated this now: https://twitter.com/avast_antivirus/status/1237685343580753925 https://twitter.com/avast_antivirus/status/12376853435807539...
- leshow 7y ago
  Id say it makes a lot of sense. You're comparing a memory unsafe language with a safe one.
  - LeoNatan25 7y ago
    The runtimes are also written in “memory unsafe languages” (C++). The runtimes bring a whole lot more code than if you wrote own tailor made code, meant to do something specific, in “memory unsafe languages”.
    - saagarjha 7y ago
      Yes, but the runtimes usually have a large amount of time and security effort invested into them.
      - armitron 7y ago
        This is not correct in my experience. I think it's more apt to say that security effort has mostly been spent around sandboxing and related technologies which is really an admission that there is no way to secure the JS VMs in themselves. The best engineers in the world can't do it. Maybe that will change if they move to safer languages, but so far nobody has done that. Therefore when you see an exposed unsandboxed VM, you instantly know it's critical issue.
        saagarjha 7y ago
        Writing secure C++ is quite hard, even for the best engineers in the world. However, that absolutely does not mean that your handcrafted C++ code is more secure than JavaScript running a virtual machine that is written in C++. The sandbox exists as another layer of defense, not because the code is inherently more insecure. (Also, it's usually because JavaScript virtual machines evaluate untrusted input, which is something that has been shown to be notoriously difficult to secure against in general.)
- saagarjha 7y ago
  > Popular JS VMs have huge attack surfaces No, not really? Depending on the browser they have generally have a small-to-medium attack surface. Yes, they can JIT, but often they can't do much else. > and are prime candidates for gray and black market vulnerability hunts Because they are remotely exploitable, nothing more. > They are often not maintained The world's deepest pockets and countless hours from the world's smartest minds go into maintaining them… > once a vulnerability is discovered, the entire app is compromised Not in modern browsers. > In the case of a highly-privileged process Oh good, so not the JavaScript process, right?
  - LeoNatan25 7y ago
    How many vulnerabilities have existed in Electron apps, sandboxing and all? I meant maintained by app developers who include the runtimes, not the runtimes themselves.
    - saagarjha 7y ago
      > How many vulnerabilities have existed in Electron apps, sandboxing and all? Significantly fewer than you'd find in a comparable C++ application, probably, and with much less effort put into securing things like "if I index into this array am I allowing for an arbitrary write primitive" and "can I safety use this object without giving an attacker code execution". Electron bugs tend to be of the sort like "oops, we can load a file from the filesystem because we forgot a string check", and C++ bugs are "that, but with the other things I just mentioned".
      - LeoNatan25 7y ago
        > probably Based on what? On C++ you have complex systems with difficult code to get correctly. With Electron, you have terrible chat apps that take 1GB of memory to display a few chat bubbles that allow remote execution into machines running them. The data to compare the two is just not there to assume anything like you just did. Meanwhile, electron apps have proven quite insecure, despite not being able to allow arbitrary write primitive by indexing into an array.
- _bxg1 7y ago
  > Popular JS VMs...are often not maintained The V8 engine, in 2020, is one of the most actively-maintained software projects of any kind. And (for better or worse) nearly everyone who needs a JS engine uses that one. This includes - among others - Chrome, NodeJS (which means Electron too), and now Edge. The only major outliers I can think of are JavaScriptCore (iOS/Safari) and SpiderMonkey (Firefox). The sin committed by Avast was rolling their own version of something, as a less-than-massive-company, when the state-of-the-art implementation is OSS. That has nothing to do with JavaScript the language. You're commenting on things you clearly know nothing about.

LeoNatan25 7y ago

Your expectation makes no sense. Popular JS VMs have huge attack surfaces, and are prime candidates for gray and black market vulnerability hunts. They are often not maintained, thus once a vulnerability is discovered, the entire app is compromised. In the case of a highly-privileged process, this can be catastrophic. Contrast this with tailor-made, slim and well tested C++ code. And yes, I do expect security companies to have well-written and well-tested code.

paraboul 7y ago
Can I invoke my @pcwalton card here? :-)
deleted 7y ago
[deleted]
detaro 7y ago
> And yes, I do expect security companies to have well-written and well-tested code. Your expectation makes no sense, given the vulnerabilities we've seen in AV software in the past decade. If they insist that executing suspect JS is a good idea, they a) probably should use an established interpreter unless there's good reasons not to and b) not run it privileged. EDIT: Avast appears to have deactivated this now: https://twitter.com/avast_antivirus/status/1237685343580753925 https://twitter.com/avast_antivirus/status/12376853435807539...
leshow 7y ago
Id say it makes a lot of sense. You're comparing a memory unsafe language with a safe one.
- LeoNatan25 7y ago
  The runtimes are also written in “memory unsafe languages” (C++). The runtimes bring a whole lot more code than if you wrote own tailor made code, meant to do something specific, in “memory unsafe languages”.
  - saagarjha 7y ago
    Yes, but the runtimes usually have a large amount of time and security effort invested into them.
    - armitron 7y ago
      This is not correct in my experience. I think it's more apt to say that security effort has mostly been spent around sandboxing and related technologies which is really an admission that there is no way to secure the JS VMs in themselves. The best engineers in the world can't do it. Maybe that will change if they move to safer languages, but so far nobody has done that. Therefore when you see an exposed unsandboxed VM, you instantly know it's critical issue.
      - saagarjha 7y ago
        Writing secure C++ is quite hard, even for the best engineers in the world. However, that absolutely does not mean that your handcrafted C++ code is more secure than JavaScript running a virtual machine that is written in C++. The sandbox exists as another layer of defense, not because the code is inherently more insecure. (Also, it's usually because JavaScript virtual machines evaluate untrusted input, which is something that has been shown to be notoriously difficult to secure against in general.)
saagarjha 7y ago
> Popular JS VMs have huge attack surfaces No, not really? Depending on the browser they have generally have a small-to-medium attack surface. Yes, they can JIT, but often they can't do much else. > and are prime candidates for gray and black market vulnerability hunts Because they are remotely exploitable, nothing more. > They are often not maintained The world's deepest pockets and countless hours from the world's smartest minds go into maintaining them… > once a vulnerability is discovered, the entire app is compromised Not in modern browsers. > In the case of a highly-privileged process Oh good, so not the JavaScript process, right?
- LeoNatan25 7y ago
  How many vulnerabilities have existed in Electron apps, sandboxing and all? I meant maintained by app developers who include the runtimes, not the runtimes themselves.
  - saagarjha 7y ago
    > How many vulnerabilities have existed in Electron apps, sandboxing and all? Significantly fewer than you'd find in a comparable C++ application, probably, and with much less effort put into securing things like "if I index into this array am I allowing for an arbitrary write primitive" and "can I safety use this object without giving an attacker code execution". Electron bugs tend to be of the sort like "oops, we can load a file from the filesystem because we forgot a string check", and C++ bugs are "that, but with the other things I just mentioned".
    - LeoNatan25 7y ago
      > probably Based on what? On C++ you have complex systems with difficult code to get correctly. With Electron, you have terrible chat apps that take 1GB of memory to display a few chat bubbles that allow remote execution into machines running them. The data to compare the two is just not there to assume anything like you just did. Meanwhile, electron apps have proven quite insecure, despite not being able to allow arbitrary write primitive by indexing into an array.
_bxg1 7y ago
> Popular JS VMs...are often not maintained The V8 engine, in 2020, is one of the most actively-maintained software projects of any kind. And (for better or worse) nearly everyone who needs a JS engine uses that one. This includes - among others - Chrome, NodeJS (which means Electron too), and now Edge. The only major outliers I can think of are JavaScriptCore (iOS/Safari) and SpiderMonkey (Firefox). The sin committed by Avast was rolling their own version of something, as a less-than-massive-company, when the state-of-the-art implementation is OSS. That has nothing to do with JavaScript the language. You're commenting on things you clearly know nothing about.