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

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

Expand Messages
  • Jakob Kruse
    ... 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
    Message 1 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.

      By supplying such an upgrade feature, which automatically (when invoked), and without security checks, downloads a program and executes it with full rights, you are setting jslint.com up as a target for such attacks. In other words, your script would become a potential virus distribution channel.

      I’m saying this because I’ve had similar considerations about a project of my own (LintServer, also on github, nowhere near distribution ready). I haven’t solved the issue there yet, but when I have, feel free to “borrow”. J

      /Jakob

      [Non-text portions of this message have been removed]
    • 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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.