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

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

Expand Messages
  • Douglas Crockford
    ... 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
    Message 1 of 11 , Feb 2, 2011
    • 0 Attachment
      --- In jslint_com@yahoogroups.com, "Jakob Kruse" <kruse@...> wrote:
      > > > > > 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.


      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. When the user installs an application, the user is not given enough information to make a correct decision.

      My advice to you is to never install applications. Ever.

      But if you do install applications, self updating applications do not make things worse. Things were always worse.
    • 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 2 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 3 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 4 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 5 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.