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

Re:So much JS hate here

[TheRaven64]

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.

There's one difference: when I use a C/C++ library, I almost always install it via my operating system's package manager. The version installed won't have been checked for backdoors, but it will at least be a released version that has gone through some minimal QA. The fact that it's included at all typically means that upstream has a half-competent release process or that some other applications are depending on it and making it worth packaging.

Newer languages all seem to feel the need to create a per-language package manager. This works fine as long as all software is written in that language, but is really painful for multi-language software (i.e. most non-trivial programs). NPM isn't quite the worst - the default way of including stuff in a Go program is to point at the upstream project's git repo and have your build environment clone the head revision and statically link it into your binary - but it's pretty bad.