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

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

Expand Messages
  • Douglas Crockford
    ... What good would that warning do? It does not give the user enough information to make a correct decision.
    Message 1 of 11 , Feb 2, 2011
    View Source
    • 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.
    • Jakob Kruse
      ... 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
      Message 2 of 11 , Feb 2, 2011
      View Source
      • 0 Attachment
        > > > > 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]
      • Rob Richardson
        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
        Message 3 of 11 , Feb 2, 2011
        View Source
        • 0 Attachment
          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]
        • 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 4 of 11 , Feb 2, 2011
          View Source
          • 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 5 of 11 , Feb 2, 2011
            View Source
            • 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 6 of 11 , Feb 2, 2011
              View Source
              • 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 7 of 11 , Feb 2, 2011
                View Source
                • 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 8 of 11 , Feb 2, 2011
                  View Source
                  • 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.