Loading ...
Sorry, an error occurred while loading the content.

SV: [jslint] Re: ANN: JSLint Reporter (Node.js wrapper)

Expand Messages
  • Jakob Kruse
    Rob, I believe I expressed my thoughts in my original post on the topic. Node.js has a built-in feature for running scripts “sandboxed”, that is without
    Message 1 of 11 , Feb 2, 2011
    • 0 Attachment
      Rob,

      I believe I expressed my thoughts in my original post on the topic. Node.js has a built-in feature for running scripts “sandboxed”, that is without any of the special Node.js features (or with as few or many of them as one wants) and permissions. In my LintServer project I started with the module approach as well, because it’s just so easy to add that one line to jslint.js. But then I gave it a lot of thought. And I convinced myself that it would be a very bad idea (due in part to the validation issues you mention) to run any version of JSLint that I had not personally checked and deemed safe in an unrestricted environment.

      I’m sure Mr. Crockford takes great care and runs a secure server, but the nature of this exploit is such that it could be some time before anyone even discovered that jslint.js had been hacked to download trojans. Or that somewhere out there on another server there was a malicious copy that some DNS servers pointed to.

      The Node.js feature I mentioned is in the VM module. Use that to run scripts that are outside of your control, or take care to alert users to the insecurities of your script. If you use those features (and use them correctly, which is not trivial), it becomes completely safe to download and run any script, because it wouldn’t have access to anything but a core V8 runtime.

      And yes, with the frequency of JSLint updates, an auto-update feature is practically a must.

      /Jakob

      PS: To comment on the post from Mr. Crockford while I was writing this, many users have by now been trained to understand the risk of installing a new application. This risk applies when installing Node.js. It also applies when installing any module for Node.js. The problem with automatic updates is that most people would automatically extend the trust they assigned the updating application to the update it downloaded. Normally that would be valid. In this scenario (downloading and modularizing a script) it is not.


      Fra: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] På vegne af Rob Richardson
      Sendt: 2. februar 2011 17:34
      Til: jslint_com@yahoogroups.com
      Emne: RE: [jslint] Re: ANN: JSLint Reporter (Node.js wrapper)


      I completely agree that security is a concern here, and the potential of
      jslint.com (or github.com) as an attack vector -- especially through
      auto-update tools into node.js -- is not without merit. I'd be hard pressed
      to believe that someone as meticulous and skilled as Douglas would allow
      that to happen though, especially to a beloved pet project. I grant this
      may be a "head in the sand" solution, but I'm comfortable with that risk.

      Towards mitigating it, would one verify that DNS still pointed to the same
      IP (defeating DNS)? Would one download the script, and verify you don't see
      anything that looks like an xhr or web url or filesystem path? Would one
      run it through the old copy of the script to see if it passed? Would one
      diff it and insure it didn't change by more than 8%? The recent addition of
      the tree is an example that breaks all these paradigms. I can't see a good
      algorithm that would validate that what you downloaded from what you
      believed to be the valid source was indeed published by the intended author.
      Neither jslint.com nor github (unauthenticated) use https, so there is no
      certificate trust chain to verify. And even an https certificate doesn't
      validate the server wasn't tampered with.

      To the other side, not updating jslint.js would give the user a false sense
      of security. That which we believed to be "the best we could do" a year ago
      is now an anti-pattern. A copy of JSLint from even 6-months ago doesn't
      inform you as much as the most recent release. Any tool that incorporated
      JSLint but didn't include update seems far more dangerous because the code
      you'll produce with it will be deemed "good" with you as the trusted author.

      What're your thoughts (aside from a distracting "are you sure" message) to
      mitigate this risk while still providing updates?

      Rob

      -----Original Message-----
      From: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] On
      Behalf Of Jakob Kruse
      Sent: Wednesday, February 02, 2011 8:41 AM
      To: jslint_com@yahoogroups.com
      Subject: SV: [jslint] Re: ANN: JSLint Reporter (Node.js wrapper)

      > > > > Do please consider the security aspects. [...] It *is* possible to
      > > > > run JavaScript code sandboxed in Node. Maybe you should consider
      > > > > that, instead of the module approach.
      > > >
      > > > While I understand and appreciate your concern, I'm not too worried
      > > > about this myself. However, I would be very happy to accept patches.
      > >
      > > At least consider informing users of your script that use of the upgrade
      feature could potentially destroy their computer. Again, all it would take
      to do that would be to inject malicious code into jslint.com.
      >
      > What good would that warning do? It does not give the user enough
      information to make a correct decision.

      In my opinion, the correct decision would be not to use such a feature - or
      use it and be prepared for any consequences. Common auto-update features
      (from apt-get to Windows Update) includes some form of security. Whether
      users are aware of that or not, they would not expect the risk of a
      destroyed or infected hard drive. If my wording lacks information, improve
      it. That's far better than having no warning at all.

      /Jakob

      [Non-text portions of this message have been removed]


      [Non-text portions of this message have been removed]
    • mathew
      ... I m sure everyone who uses JSLint will agree that it s evil... it s just a question of whether it will damage your data. Seriously, though, you could
      Message 2 of 11 , Feb 2, 2011
      • 0 Attachment
        On Wed, Feb 2, 2011 at 11:25, Douglas Crockford <douglas@...>wrote:

        > The problem isn't that the code can be replaced with evil code. The problem
        > is that the code could always have been evil, and the all code that runs as
        > an application is granted too much power.
        >

        I'm sure everyone who uses JSLint will agree that it's evil... it's just a
        question of whether it will damage your data.

        Seriously, though, you could provide a digital signature which could be
        checked.


        mathew


        [Non-text portions of this message have been removed]
      • Douglas Crockford
        ... A digital signature does not make things less worse. It is false security.
        Message 3 of 11 , Feb 2, 2011
        • 0 Attachment
          --- In jslint_com@yahoogroups.com, mathew <meta404@...> wrote:
          > Seriously, though, you could provide a digital signature which could be
          > checked.

          A digital signature does not make things less worse.
          It is false security.
        • Frederik Dohr
          ... I agree that this would be the ideal solution - and looking at your LintServer*, it appears you ve already solved this issue (I must have misunderstood you
          Message 4 of 11 , Feb 2, 2011
          • 0 Attachment
            > Node.js has a built-in feature for running scripts “sandboxed” [...]
            > The Node.js feature I mentioned is in the VM module. [...] If you use
            > those features (and use them correctly, which is not trivial), it
            > becomes completely safe to download and run any script

            I agree that this would be the ideal solution - and looking at your
            LintServer*, it appears you've already solved this issue (I must have
            misunderstood you before):
            vm.runInNewContext(fs.readFileSync('./fulljslint.js', 'utf8'),
            sandbox, 'fulljslint.js');

            This appears to work just fine:
            https://gist.github.com/809174
            (untrusted.js throws exceptions since it doesn't have access to require)

            It should be rather straightforward to add this to JSLint Reporter then.


            -- F.


            * https://github.com/jkruse/LintServer/blob/master/lintserver.js
          Your message has been successfully submitted and would be delivered to recipients shortly.