Somebody Tried to Hide a Backdoor in a Popular JavaScript npm Package (bleepingcomputer.com)

Catalin Cimpanu, reporting for BleepingComputer: The Node Package Manager (npm) team avoided a disaster today when it discovered and blocked the distribution of a cleverly hidden backdoor mechanism inside a popular -- albeit deprecated -- JavaScript package. The actual backdoor mechanism was found in "getcookies," a relatively newly created npm package (JavaScript library) for working with browser cookies. The npm team -- which analyzed this package earlier today after reports from the npm community -- says "getcookies" contains a complex system for receiving commands from a remote attacker, who could target any JavaScript app that had incorporated this library.

Comments

And that's why we can't have nice things

[Anonymous Coward]

As a Dev NOT working with JS and NPM: Given the vast number of packages on NPM https://developers.slashdot.org/story/17/01/14/0222245/nodejss-npm-is-now-the-largest-package-registry-in-the-world I'd wager a pretty penny there are more foul packages out there.
Dependency managers like Maven, Gradle, NPM, Pipenv and Bundler have made linking against other peoples libraries a walk in the park. Regardless if you draw your packages from public servers or your private Artifactory Server.

YOU are the Developer. It is YOUR obligation to ensure you don't link to bogus, questionable or potentially malicious libraries.
They spotted that one on time, but rest assured, there are probably hundreds of other packages out there (not only on NPM) that are either faulty, insecure or downright malicious.

We should take this as a shot across the bow. Be vigilent and don't rely on the competence of others to sort out the rotten apples for you. Think twice before you include some nifty lib into your project. If in doubt, get the source code (where available) and vet the source you got the binary from. Developers supplying packages should have their packages cryptographically signed for their own protection. It's not like this technology didn't exists. We only don't use it out of convenience and trust me ... the road to hell the most convenient one there is.

Re:And that's why we can't have nice things

[skids]

YOU are the Developer. It is YOUR obligation to ensure you don't link to bogus, questionable or potentially malicious libraries.

Any library can become bogus and malicious at any given time. One compromised laptop and a keystroke logger to get the DSA key+password is all it takes. I don't think many developers would sign up for a system of "if you write code, you have to stick around and watch that code and all its dependencies vigilantly" because you'd have to stop writing code at age 25 and spend the rest of your life on the full-time job of monitoring what you wrote. The point of volunteer OSS is you are supposed to be able to contribute what you are willing to, when you want to.

Libraries are a double-edged sword security-wise... bugs and compromises in them affect everything, but on the bright side, you only have to fix them in one place, not hunt variants of them down in the thousands. (Not to say that there are not tons of completely redundant libraries due to NIH, megalomania, or just not being aware of other solutions.)

When you see something like TFA happen you need only ask: what work was too menial for anyone to do on a volunteer bases that this was not caught and then you know what the OSS community needs to find someone to pay someone to do.

Re:Newly created, popular, and deprecated

[The Fat Bastard]

You must not be familiar with JavaScript development. The moment you learn a JS framework, ten more JS frameworks will pop up and your newly learned JS framework will already be depreciated.

So much JS hate here

[Arkham]

I don't personally do any significant JS development, but the suggestion that this is a JS-specific problem is silly. This could have just as well been in a Java or C++ framework. We all use third party libraries and frameworks all the time without doing a line-by-line code review.

The real story here isn't that someone tried to slip in a backdoor. The story should be about how the NPM team did their due diligence and protected all of their users by catching this. Good job to them.

Re:Frameworks

[The MAZZTer]

So I guess we should just give up on Linux with yum, rpm, and apt?

Also nuget for .NET stuff but Linux makes a better example.

Dangers of relying on the Tower of Abstraction

[ErichTheRed]

We all know that JavaScript is a pretty messy language to work with unless you're using some sort of framework. Part of that is that it's been pushed to do way more than it ever was designed to do and is hyper-complex as a result.

I guess my question is how far up the abstraction tower goes. Why would developers pull hundreds of libraries from dozens of sources just to build a simple program? And more importantly, why would you dynamically pull these resources instead of building against a known-good set, and only update one of your dependencies when you've tested it completely?

I know software is all about move-fast-and-break-things these days, but the "trust the Internet implicitly for all my source packages" is one thing I can't get my head around.