Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Get HideMyAss! VPN, PC Mag's Top 10 VPNs of 2016 for 55% off for a Limited Time ×
Open Source Programming Security

New Attack Discovered On Node.js Package Manager npm (softpedia.com) 90

An anonymous reader writes: A Google researcher has discovered a way in which he could exploit some npm registry design flaws to propagate a malicious package to other packages, and in the projects that load them. The exploit leverages things such as npm's persistent authentication, developers who never lock down dependencies (and often use version number ranges), npm lifecycle scripts that run with the user's privileges (sometimes as root), and npm's centralized registry, which doesn't review or scan code. Attackers can compromise other projects with malicious code, can compromise Node apps used in corporate environments, or they can launch worm-like viruses that poison npm packages at random.
This discussion has been archived. No new comments can be posted.

New Attack Discovered On Node.js Package Manager npm

Comments Filter:
  • by Anonymous Coward

    How much would it take to spread? If something like this gets added to Express or an Express dependency, I would imagine it would contaminate tens of thousands of products in one day.

    • by Anonymous Coward on Sunday March 27, 2016 @10:41AM (#51786679)

      How do we know that such techniques haven't already been used?

      Even if they fix these flaws, I think every single line of code in every single version of every single npm package will need to be reviewed by a team of security experts.

    • If it got into something like a 'pad-left' then it would spread really quickly.
    • Remember those ads from the 80s and 90s about how sleeping with one person is like sleeping with all the people they slept with? Node and NPM are like that, if you slept with Charlie Sheen. It's like everybody is having a contest to see how many dependencies they can require. Who knew it takes 3 dependencies to figure out if a number is positive?
  • by Anonymous Coward

    I can sort of understand using JavaScript in the browser. After all, it's the only option. But server-side?! There is no such restriction!

    Why the heck would anyone choose to use such an awful, crippled language when they have numerous superior options?!

    It baffles my mind how somebody would go out of their way to use such an awful language when there are so many better options available.

    I'm not one to pre-judge. I tried out JavaScript, Node.js and npm for myself. I couldn't believe just how awful they were!

    • Re: (Score:3, Informative)

      by Anonymous Coward

      Because cheap code monkeys cannot write real code.

      • by gweihir ( 88907 )

        Because cheap code monkeys cannot write real code.

        Sad, but true. We do not have to few coders. We have far too many and most of them bad.

        • More to the point, we have far too many coders who are not interested in the craft. They are interested in a paycheck and that's where their interest ends. They are not interested in increasing the depth or breadth of their knowledge and abilities. Compounding the problem, we have far too many management types who are not at all interested in code done right as long as it's done by the deadline.
    • by i.r.id10t ( 595143 ) on Sunday March 27, 2016 @10:48AM (#51786711)

      Aside from that, why are libraries pulled in dynamically from the intertoobs on a production server? Why aren't the libraries packaged like Perl CPAN stuff, or PHP PEAR stuff, to be downloaded (and signature verified?) to the server or dev machine and accessed only locally? Heck a tar.gz file with a posted list of hash sums would be more secure. This is all old hat stuff that has been solved in multiple ways, no reason at all for it to be an issue now.

      • by Junta ( 36770 )

        The problem being is that they use the other repositories in the same way. Sure you *can* download and go, but overwhelmingly, people use the automated install.

        Meaning that if people 'pip install' a package of mine that has a dependency, the chances are that my dependencies are such that you'll get latest of 'whatever' without verification and potentially without any test.

        Either more people or at least louder people are doing this more and more. This is a problematic strategy for the same reasons a rollin

      • npm does not require you to install packages from the registry and your application's package.json dependencies do not either.

        For production you can very easily have your own internal git server hosting your packages and dependencies, at specific verified versions.
        Or if you don't like git you could have an internal SSL/TLS server hosting tarballs of all of the packages/dependencies.

        The npm registry makes sharing packages easy but nothing says you have to use code straight from that to production.
        Hell, you d

    • by Anonymous Coward

      When your only too is a javascript interpreter, every problem looks like the back of the CEO's head.

    • Re: (Score:3, Informative)

      When you are fluent in one language you speak that language even if there are better options.
    • I'm not sure how JavaScript would be that different than any other scripting language (Perl/Ruby/Python/PHP/Groovy), and those seem to have viable web ecosystems Not 100% sure where the hate for JS is coming from. Unless it's a disdain for scripting languages in general. That would generally leave you with C#/Java and Java, historically, has been the only cross platform solution, and the language has stagnated heavily over the last decade (though 1.8 and 1.9 are showing signs of life).
      • by Junta ( 36770 )

        My primary gripe with Javascript is that it really shows it was a scripting language for light use to liven up browser content a little bit, and overused from there.

        It's a serviceable language, obviously, but the same factors that have Perl tempting developers to make hard to maintain code are present in Javascript (a whole slew of syntaxes for the identical thing), though it's a bit more extreme in Javascript. Also a tendency for certain functionality to look almost like an accidental behavior (e.g. 'obje

        • by SavedLinuXgeeK ( 769306 ) on Sunday March 27, 2016 @12:29PM (#51787161) Homepage
          Javascript has some terribly bad parts (as does perl and php) and I would concur that languages like Python/Ruby seemed to be planned in entirety a bit more. I would recommend looking at ES2015+, the next revision of the Javascript. It does a lot to curb those issues (JS actually has a "strict" mode that handles some of the gotchas), and ES2015 adds proper module support, as well as a standard class syntax.

          These features have been in use for years by transpilers (to cover the gap between agreement on a new language feature and the time before it is adopted by the runtimes). Typescript is an even more powerful extension of ES2015 that adds compile-time type analysis/verification but generates nearly perfect idiomatic ES2015 code.
          • by Junta ( 36770 )

            The problem being:
            A) It's of limited comfort if you have to support a lot of browsers, with uneven support. Less dysfunctional than it used to be, but for example a KeyboardEvent to this day won't have a 'key' attribute in most *new* Webkit/Blink browsers, despite it being around for years.

            B) A lot of the syntax for new things have to settle for approaches that are compatible with existing syntax. For example, requesting strict is a bare string 'use strict' string just hanging out. Arrow expression synta

            • From a runtime environment, I agree there are lots of "quirks", and the DOM is one of the worst cross-platform interfaces of all time. Less of a contract and more of wishes and hopes. ES2015 really does focus on syntax (e.g. "use strict" is default when using modules and not required). "this" has always been a gotcha, but that is part of a language where the function is the unit context. I actually like that about Javascript (though I realize not everyone does). For that reason "let" was also introduce
              • by Junta ( 36770 )

                Oh, I personally have found 'this' to be quite useful as it works in a number of scenarios (in the original application of futzing about with the DOM, the value of this is highly relevant). It's just an interesting example of offering multiple behaviors in different contexts. If you use an arrow expression, then this is similar to the concept as found elsewhere. If you use bind(), then this is always whatever gets bound (which can be an entirely different thing altogether).

                I still maintain that as a lang

                • As a server side language, I'm extremely torn. I've actually been using Typescript pretty heavily lately (and decorators), and it makes the code I write not too far off from the Spring/Java code I would generally write. My biggest concern with NodeJS is the maturity of the ecosystem, and how it plays with enterprise software development. One of my goto examples is LDAP support. There were a handful of libraries (circa 2014) that sort of worked, but had gaps, and ultimately required doing some odd tricke
    • I can sort of understand using JavaScript in the browser. After all, it's the only option.

      With WebAssembly, soon it won't be the only option in the browser. You'll be able to use APL for browser programming (if you can find a good keyboard somewhere).

    • by creimer ( 824291 )

      It baffles my mind how somebody would go out of their way to use such an awful language when there are so many better options available.

      Most people don't consider PHP to be a better option.

      • Most people don't consider PHP to be a better option.

        One could name perl or python... but then, compared to node.js and PHP, assembler and brainfuck are better choices.

        • by creimer ( 824291 )

          One could name perl or python...

          I'm using a Python-based static website generator for my website. No more MySQL or PHP attacks from hackers in Russia and Asia. Being able to load web pages in three seconds is also a nice bonus.

    • Node.js is for people too stupid to learn PHP.
  • by BenJeremy ( 181303 ) on Sunday March 27, 2016 @10:42AM (#51786681)

    Petulant developers save the internets!

  • by Anonymous Coward on Sunday March 27, 2016 @10:55AM (#51786733)

    Wait... there are people who run Javascript code, on a server, as root? Untrusted Javascript code they don't control to boot? Uhhh, wow.

    • by El_Muerte_TDS ( 592157 ) on Sunday March 27, 2016 @12:38PM (#51787193) Homepage

      wget -O- https://example.org/install.sh [example.org] | sh

      is a very common installation method presented by various tools (or via curl). In most cases you even need to run them as root due to the fact that the creators of those tools do not understand how to have their software work as non-root users.

      For example:
      https://toolbelt.heroku.com/de... [heroku.com]
      https://docs.docker.com/linux/... [docker.com]
      https://nodejs.org/en/download... [nodejs.org]

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        I tend to see "curl" more often than "wget -O-", but it's the same problem.

        And when a software project recommends

        curl (some url) | sh

        I assume that the developers arrogant or incompetent.

        When the project recommends

        curl (some url) | sudo sh

        I assume that the developers are incompetent or malicious.

        But I'm a greybeard.

        The sad thing is that I've met bright, young developers who don't see it as a problem. "That's how the Internet works," they say, pointing at Javascript on the web. (I grind my teeth at JS+HTTP ==

    • by leptons ( 891340 )
      Wait... there are people who run Ruby code, on a server, as root? Untrusted Ruby code they don't control to boot? Uhhh, wow.

      Wait... there are people who run PHP code, on a server, as root? Untrusted PHP code they don't control to boot? Uhhh, wow.

      Wait... there are people who run Python code, on a server, as root? Untrusted Python code they don't control to boot? Uhhh, wow.

      FTFY...

      It isn't about the language, it's about package management. Singling out Javascript makes you look like an idiot because yo
  • by Anonymous Coward

    npm as a concept seems susceptible to failures of different kinds. If I were to build a long-life system around Node.js, this could be a problem.

  • by Anonymous Coward

    I argue this with other devs a lot. Dependency managers, *especially* if you use version wildcards, are asking for trouble. Keep more of a handle on what your dependencies are, and only move versions if there's a compelling reason (security update, huge performance boost, etc).

    • by Junta ( 36770 )

      It really depends on the real audience.

      What I like to do is offer two paths to download. One via a channel like CPAN or such, and as a package repository. If someone asks 'how to run the code' I say 'add this package repository (yum/apt) that we support and maintain', and there we are strict about the dependencies, mirroring, updating, and testing them. There's a dependency that sees a major release? Good for them, they aren't in the repository until they get tested. The users of the yum/apt get priori

  • by Anonymous Coward

    I'm not a young hipster. I'm an oldie who has worked in a dozen or more languages over the years. Starting with Algol back in the day. I have worked on all kinds of systems from industrial control, safety critical avionic flight controls, CAD systems, and yes the web.

    I was very surprised to find out a few years ago that the stupid Javascript language, you know that simplistic and slow scripting language use by web-monkeys to respond to mouse events and animate useless crap in the browser, is actually quite

    • by leptons ( 891340 )
      You're the only other sane person in this thread. I know this is slashdot, and it's full of anti-javascript hatred to it's core, but all these comments overlook that this isn't a javascript problem, this is a package manager problem which other languages also have. Nothing about this is really specific to javascript at all, but it's an all-too-convenient reason to bash javascript yet again in an online forum that has jumped the shark many years ago.
  • Where's the "Why don't they use Rust" guy?

Where there's a will, there's a relative.

Working...