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

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

Expand Messages
  • mathew
    ... The attacker wouldn t even need to do that. They could just redirect jslint.com to a site they control via DNS poisoning. mathew [ A lesson Sony may soon
    Message 1 of 11 , Feb 2, 2011
    • 0 Attachment
      On Wed, Feb 2, 2011 at 07:50, Jakob Kruse <kruse@...> wrote:

      > 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.
      >

      The attacker wouldn't even need to do that. They could just redirect
      jslint.com to a site they control via DNS poisoning.


      mathew
      [ A lesson Sony may soon learn, apparently. ]


      [Non-text portions of this message have been removed]
    • Douglas Crockford
      ... What good would that warning do? It does not give the user enough information to make a correct decision.
      Message 2 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.
      • 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 3 of 11 , Feb 2, 2011
        • 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 4 of 11 , Feb 2, 2011
          • 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 5 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 6 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 7 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 8 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 9 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.