13 ms·

NPM package ‘ua-parser-JS’ with more than 7M weekly download is compromised

255 points by geocrasher 5y ago

mike-cardwell 5y ago
Seems like a good time to plug my project https://gitlab.com/mikecardwell/safernode https://gitlab.com/mikecardwell/safernode
deleted 5y ago
[deleted]
aasasd 5y ago
Pretty sure that every time (or almost every time) when I run `npm install` in a repo downloaded from Github, NPM complains about several security problems in the dependencies. Kinda feels like an unending ‘cry wolf’ situation.
- maaanu 5y ago
  Exact the same analogy Dan Abramov used in his blog: https://overreacted.io/npm-audit-broken-by-design/ https://overreacted.io/npm-audit-broken-by-design/
ahuth 5y ago
Submitted link is to a reddit thread. Better one might be the GitHub issue discussing it: https://github.com/faisalman/ua-parser-js/issues/536 https://github.com/faisalman/ua-parser-js/issues/536
- flanbiscuit 5y ago
  which has already been submitted here: https://news.ycombinator.com/item?id=28960439 https://news.ycombinator.com/item?id=28960439
olex 5y ago
Maintainer already released clean versions "on top of" the compromised ones, and NPM acted on reports and removed the compromised versions as well. Compromised (and no longer downloadable from NPM): - 0.7.29 - 0.8.0 - 1.0.0 Clean: - 0.7.28 (last version before the hijack) - 0.7.30 - 0.8.1 - 1.0.1 Compromised versions apparently contained a cryptomining tool capable of running on Linux, and a trojan that extracts sensitive data (saved passwords, cookies) from browsers on Windows. Both are blocked by up-to-date Windows Defender and presumably other AV software.
meibo 5y ago
NPM/any package manager should not let you upload/manage packages with more than 1k downloads a month without 2FA. It's a liability and this is bound to happen.
- ferdowsi 5y ago
  Does any package ecosystem do this? Rust had the opportunity to start off doing the right thing but instead uses long-lived API tokens which can get easily owned.
  - christophilus 5y ago
    NPM supports TOTP, but it’s opt in.
- koolba 5y ago
  I’ve been saying this for years: https://news.ycombinator.com/item?id=17514541 https://news.ycombinator.com/item?id=17514541 Though rather than mandating it, just show if the publisher has it enabled and let the market decide.
  - thenickdude 5y ago
    Yes, I'd love it if NPM would mark any package as insecure if it transitively depended on a developer that didn't use 2FA.
- eyelidlessness 5y ago
  IMO they—NPM especially—should also prevent publishing arbitrary packages where the source is accessible. In such cases, `npm publish` should be an authorization check and run your publish lifecycle to produce the package. It’s absolutely bonkers that an ecosystem where the vast majority of packages are permissively licensed allows those packages to be published with basically whatever the heck you want, completely independent of whatever you would find inspecting and building it yourself.
- mnahkies 5y ago
ipnon 5y ago
This is the price of free code. If you don't read the open source you're adding to your system then don't complain when it owns you! You wouldn't take your medicine without reading the label first. NPM is a miracle for open software development, but it requires diligence.
- trog 5y ago
  Weird comparison. The equivalent with medicine is not 'reading the label', but understanding the chemistry, reading all the research, reading all the associated papers, understanding all the biology, etc. It's reduced to you needing to only read the label by regulation. Expecting people to read the source of their dependencies, outside of very specific use cases and industries, is a lost cause.
  - shukantpal 5y ago
    The difference is that NPM packages are provided for free.
    - Zababa 5y ago
      Many drugs are free or almost free where I live. Well, not really free, they're paid by our taxes. And npm is paid by Microsoft not paying theirs. So the difference isn't so big.
      - shukantpal 5y ago
        "And npm is paid by Microsoft not paying theirs." LOL ok.
  - maccolgan 5y ago
    Imagine if you needed a doctoral degree and a billion dollar FDA study before being able to publish open source code.
- LinuxBender 5y ago
  Unless these are compiled binaries it should be fairly easy to spot funny-business. Surely someone out there must do diffs on version updates to see what changed. I know that I am nosey enough to see what changes people made rather than relying on change logs. Either way it would be nice if NPM devs signed their scripts. Nothing as complex as rpm/deb packages, just corresponding .asc files might be useful for the small handful of people that validate signatures. Or if public key management is a PITA and too much friction, then even a signed manifest file on a trusted origin server vs. mirrors could be super handy. The code deployment systems could curl the manifest and at least validate the checksums of the files.
alienalp 5y ago
For packages that popular, authority of more than one people should required or at least some kind of delay until npm update/install command catch it unless specifically that version set. If i remember correctly if someone hijacked my npm account and published something i wouldn't even noticed it. Obviously publisher should get an email or maybe even sms.
- 8organicbits 5y ago
  The delay idea sounds promising. I'd want that as part of npm, but I suppose someone could build an NPM proxy that adds the delay. Has anyone tried something like this, even for a different ecosystem?
  - seniorsassycat 5y ago
    It's possible with AWS CodeArtifact using EventBridge to promote after a delay. The company I work for has a three day delay on npm.
- okhobb 5y ago
  A large part of npm's staggering success is the very low friction to publish packages. I worry that any mitigation that slows down the publishing side of things would kill innovation in the ecosystem.
  - 8organicbits 5y ago
    I imagined an optional delay for npm install/update. That way it would only slow down users who wanted more time.
    - alienalp 5y ago
      It makes so much sense, surprised me that it doesn't exist.
    - okhobb 5y ago
      Got it. Yea I agree that's useful and easy mitigation, and I'm sure enterprise users would certainly pay for other safety labeling/filtering/signing of packages.
eemax 5y ago
We pin all of our npm dependencies and upgrade them via dependabot. Dependabot links to the GitHub or GitLab release for each dependency bump, and I typically skim / scan every single commit to each dependency. But there's no guarantee that what's on GH matches what is uploaded to npm (which is what happened in this case; there are no malicious commits). Does anyone know of a good way to verify that a npm release matches what's on GH? Version controlling the entirety of node_modules/ and running untrusted updates in a sandbox would work in theory, but in practice many packages contain minified js which makes the diffs between version bumps unreadable.
- pwdisswordfish0 5y ago
  Skip the nonsense and just check your dependencies in directly to your repo. The separation has no real world gains for developers and doesn't serve anyone except the host of your source repo. As it turns out most people's repo host is also the operator of the package registry they're using, so there aren't even theoretical gains for them, either. Doing it this way doesn't preclude the ability to upgrade your dependencies, it _completely_ sidesteps the intentional or unintentional desync between a dependency's source and its releases, it means people have to go out of their way to get a deployment that isn't reproducible, and in 4 years when your project has rotted and someone tries to stand it up again even if just temporarily to effect some long-term migration, then they aren't going to run into problems because the packages and package manager changed out from beneath them. I run into this crap all the time to the point that people who claim it isn't a problem I know have to be lying.
  - ncallaway 5y ago
    > I run into this crap all the time to the point that people who claim it isn't a problem I know have to be lying. I don't think that's right. Just because someone denies a problem exists—a problem that you know for a fact, with 100% certainty exists—doesn't mean they're lying. It may mean you know they are wrong, but wrong != lying, and it's a good thing to keep in mind. If you have external reasons to believe that the person you're talking to should or does know better, then it's fair to say they are lying. But, in general, if you accuse someone who is simply wrong to be lying, you're going to immediately shut down any productive conversation that you could otherwise have.
schleck8 5y ago
This appears to affect other popular packages as well, e.g. fbjs. It‘s time for proper supply chain security, the typo- and namesquatting minefield that is Pypi shows clearly why there is a need. Way too easy to distribute malware this way or register repos for popular packages by appending a version number for example. I‘m constantly running into shady deserted packages. Why not partnering with a large security vendor? The infrastructure is often provided as a donation from cloud providers as well
gnu8 5y ago
I don't know why anyone would auto-download untrusted packages as part of their own build/release chain and not review the code manually. Anything could be in there. The way people use NPM is pure fucking insanity.
- austincheney 5y ago
  Convenience and invented here syndrome. https://en.m.wikipedia.org/wiki/Invented_here https://en.m.wikipedia.org/wiki/Invented_here
- Aeolun 5y ago
  I mean, the alternative is reviewing 3000 packages by hand. No thanks. I’ll trust Snyk to let me know if anything is compromised.
  - junon 5y ago
    Snyk is okay but I've had my issues with them. Never put all of your eggs in one basket.
    - ranguna 5y ago
      Could you elaborate on those issues ?
  - gnu8 5y ago
    I suspect a huge fraction of those packages need to be rolled up into a standard library for which some foundation can take money and do proper release engineering.
    - qudat 5y ago
      But then aren’t you still trusting a third-party to properly audit their own code and ensure it doesn’t get compromised? Where’s the line?
      - 5y ago
tppiotrowski 5y ago
“ I noticed something unusual when my email was suddenly flooded by spams from hundreds of websites (maybe so I don't realize something was up, luckily the effect is quite the contrary).” I’ve been running a small deal aggregation and notification website for 15 years. Almost no new users these days. A few months ago I was excited to see dozens of new accounts created each day but no one ever clicked the verification link that was sent to their email. That’s when I first learned that creating unused accounts is a technique used by hackers to flood people’s inboxes to hide fraudulent purchases or other nefarious activity like publishing a hijacked npm package. A simple what is x + y? captcha solved the issue.
eyelidlessness 5y ago
There is an open NPM “audit assertions”[1] RFC which would allow the compromised package to be nested one dependency deeper, and would allow the hijacked ua-parser-JS package to assert that it’s unaffected. Should this proposal go through, it’s quite possible this would have gone much further. It would have allowed the attacker to wait for detection, and to silence any propagation of that to users of the otherwise legitimate package. I had to bow out of the conversation because I didn’t feel like I could engage it in a healthy way—I’m way too personally affected by my own experience dealing with dismissal of serious security issues—but I think folks here might be interested in it given this compromise. 1: https://github.com/npm/rfcs/pull/422 https://github.com/npm/rfcs/pull/422
- ComputerGuru 5y ago
  Wow. That takes the lax attitude towards security in the NPM world to a whole new level.
  - eyelidlessness 5y ago
    To be fair to the proposal’s advocates and the person who posted the blog article which prompted it: they’re not wrong that npm audit is mostly irrelevant noise and actively harmful (incentivizes individuals to ignore meaningful security issues) because of that. Their proposal is just the wrong solution, and last I checked in they were too wedded to it.
  - oefrha 5y ago
    npm audit is pretty damn meaningless at the moment. Creating a bog-standard react app with create-react-app (`npx create-react-app my-app`) right now results in > 68 vulnerabilities (21 moderate, 45 high, 2 critical) Even installing the latest npm itself (`npm install -g npm@8.1.1`) results in > 3 moderate severity vulnerabilities
    - bjornstar 5y ago
      create-react-app made their own security problems by bringing in the entire world, npm audit just makes that clear. npm itself having vulnerabilities is a more serious problem and it's not clear that they're taking it seriously.
ComputerGuru 5y ago
Why is this a link to Reddit? Usually that’s when the link is to the specific Reddit discussion because that’s what is being shared, but that’s not the case here. @mods I think the link should be to the actual post here: https://github.com/faisalman/ua-parser-js/issues/536 https://github.com/faisalman/ua-parser-js/issues/536
paxys 5y ago
I wish NPM had an option to disallow pulling dependencies from accounts that don’t use 2FA. Even if you trust a publisher it is so easy for their packages to get compromised because they are lax about security.
ievans 5y ago
Our approach to solving this on our open source project: 1. Enforce use of lock files 2. On any PR that changes any hash in the lock file, run a static analysis that looks for “permission” changes in any source file. E.g., used network, used env vars, used filesystem 3. Comment on the PR with any observed permission changes It is very alpha-quality and not yet generally available but here are some details: https://deps.semgrep.dev/ https://deps.semgrep.dev/
- Osiris 5y ago
  An unfortunate side-effect of this type of system, in my experience, is that you end up being stuck on very old dependencies for a very long time. When a security issue is discovered, perhaps months or years later, it is extremely difficult to upgrade because 1) the patch will always be applied to the most current release, which could be many major versions beyond what you run, and 2) manually backporting the security fix is impossible without creating your own fork and the code will likely be so different as to not be able to cleanly apply the patch. You are creating so much friction to update dependencies that you will find yourself unable to update them in the future. Small example: I recently upgraded a dependency that required us to move from node 12 to node 14. That required us to upgrade more packages, including our database ORM. The ORM was 2 years out of date. Now we have changes that literally affect the entire application and require significant regression testing (automated and manual) because the risk surface is so much larger. This wouldn't have happened if we didn't use a lock file with pinned versions. ------ In the past (node 4.x), lock files weren't written by default, and I (on a small project) had sufficient test coverage that always allowed NPM to install the latest minor version bump of every package, every time. If there was a problem caught by the tests, then I immediately fixed the issue with the upgrade. The nice thing about this is that I was always on the latest version of every dependency, so I always had the latest security fixes, and the online docs for the dependencies were always accurate to what I was using. If this particular exploit happened, it would have been more likely to get deployed but it would have also automatically gotten fixed as soon as the patch update rolled around. Whereas with a lock file, someone may have updated it and then not been aware when the "fixed" version came out because npm/yarn don't tell you that. As a JavaScript dev (full stack) I think lock files are a bad idea by making us LESS secure, not more (keeping around insecure older dependencies that can't be patched).
intruder 5y ago
I was actually about to use this package last week. Damn what a timing.
roofwellhams 5y ago
- steals cookies and browser data on windows: this means your browser cookies and all logged in accounts might be compromised. Maybe even passwords saved in browser. I'd even extend to password manager extensions. - crypto miner on both platforms - maybe: changes registry for existing crypto miners
godmode2019 5y ago
This is what I don't like about JS world. I started a project in react and it installed like 100+ random packages. I had to audit everyone, so silly not to have a standard library.
- ranguna 5y ago
  You want a standard library for... React? What about the people that like Vue or angular more than react?
  - HamburgerEmoji 5y ago
    I think the suggestion was that there's this crazy explosion of transitive dependencies because JS is not 'batteries included' with some standard library that covers quite a lot of what people want. If there's no standard library, you have to include some libraries to do what you want. Those libraries had no standard library to depend on either, so they had to do the same thing you did. And so on.
crehn 5y ago
The JavaScript culture around dependencies is baffling to me. The simplest of tools will easily have hundreds of transitive dependencies, making these sort of events a mess to deal with, and causing the blast radius to be avoidably large.
- userbinator 5y ago
  Left-pad was already a warning sign that something is seriously wrong with the culture. https://news.ycombinator.com/item?id=11348798 https://news.ycombinator.com/item?id=11348798
  - Zababa 5y ago
    The worst thing about it is that now left-pad is in the standard (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/padStart https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...), but that's it. is-odd has more than 400k weekly downloads https://www.npmjs.com/package/is-odd https://www.npmjs.com/package/is-odd.
    - imtringued 5y ago
      https://github.com/helpers/handlebars-helpers/issues/315 https://github.com/helpers/handlebars-helpers/issues/315 This is the only package that even uses (is even includes is odd) it while having more than 10 weekly downloads.
- GordonS 5y ago
  IMO this is largely a side effect of the JavaScript standard library being so anaemic - if available functions were bolstered significantly, it would eventually have some impact on this madness.
Ros2 5y ago
Semi-related: Microsoft is going to be (or has begun) checking for differences between published npm packages and their source control. I got a PR in my repository a few days ago leading back to a team trying to make it easier for packages to be reproducible from source https://github.com/microsoft/Secure-Supply-Chain https://github.com/microsoft/Secure-Supply-Chain
- mnahkies 5y ago
  How will this work with say typescript? It's pretty common to not commit the transpiled code - do you expect this to change, or would this check basically do a build + pack and then compare?
  - Ros2 5y ago
    Yes it will have to do that. Some packages .npmignore the source files so those may not even be present. But doing that is actually easier than having to deal with all the different ways of versioning packages. For example, I am not using git tags in my project, some others may be, some may be using a branch not named `master` to deploy from. They're going to have to intelligently traverse the git tree to draw meaningful conclusions.
Zababa 5y ago
I'd encourage everyone to try the npm fund command (https://docs.npmjs.com/cli/v7/commands/npm-fund https://docs.npmjs.com/cli/v7/commands/npm-fund) on their repos to see how many projects need funding. All of these projects are an opportunity for a malicious actor to offer a lump sum of money to get the package.
knadh 5y ago
That the package is downloaded 7 million times a week exacerbates the impact significantly. The CI/CD trend of pulling everything from upstream over and over for builds (despite caching, as the absurd NPM download counts indicate) ensures that any upstream issue is distributed widely and frequently. Continuous Integration and Continuous Deployment of vulnerabilities.
technion 5y ago
I'm usually pretty critical of tiny NPM modules, but I really want to support whoever maintains this package. Hundreds of lines of regexes, people asking about IE8 support, and a constantly moving target every time a browser changes something. This really must be a horrible package to maintain.
- rudian 5y ago
  That’s their own fault. No one needs to “detect” random esoteric browsers. Once you have 4/5 detections you should be good. IE8’s UA hasn’t changed in forever, so you could just copy-paste one of the many regexes online and keep it unchanged.
darepublic 5y ago
A stupid dependency for user agent parsing.. just becoming more and more disillusioned with the js ecosystem. And then this. And at work the junior devs turning to random npm packages for every little thing.

255 points by geocrasher 5y ago

Seems like a good time to plug my project https://gitlab.com/mikecardwell/safernode https://gitlab.com/mikecardwell/safernode

deleted 5y ago

[deleted]

aasasd 5y ago

Pretty sure that every time (or almost every time) when I run `npm install` in a repo downloaded from Github, NPM complains about several security problems in the dependencies. Kinda feels like an unending ‘cry wolf’ situation.

maaanu 5y ago
Exact the same analogy Dan Abramov used in his blog: https://overreacted.io/npm-audit-broken-by-design/ https://overreacted.io/npm-audit-broken-by-design/

ahuth 5y ago

Submitted link is to a reddit thread. Better one might be the GitHub issue discussing it: https://github.com/faisalman/ua-parser-js/issues/536 https://github.com/faisalman/ua-parser-js/issues/536

flanbiscuit 5y ago
which has already been submitted here: https://news.ycombinator.com/item?id=28960439 https://news.ycombinator.com/item?id=28960439

olex 5y ago

Maintainer already released clean versions "on top of" the compromised ones, and NPM acted on reports and removed the compromised versions as well. Compromised (and no longer downloadable from NPM): - 0.7.29 - 0.8.0 - 1.0.0 Clean: - 0.7.28 (last version before the hijack) - 0.7.30 - 0.8.1 - 1.0.1 Compromised versions apparently contained a cryptomining tool capable of running on Linux, and a trojan that extracts sensitive data (saved passwords, cookies) from browsers on Windows. Both are blocked by up-to-date Windows Defender and presumably other AV software.

meibo 5y ago

NPM/any package manager should not let you upload/manage packages with more than 1k downloads a month without 2FA. It's a liability and this is bound to happen.

ferdowsi 5y ago
Does any package ecosystem do this? Rust had the opportunity to start off doing the right thing but instead uses long-lived API tokens which can get easily owned.
- christophilus 5y ago
  NPM supports TOTP, but it’s opt in.
koolba 5y ago
I’ve been saying this for years: https://news.ycombinator.com/item?id=17514541 https://news.ycombinator.com/item?id=17514541 Though rather than mandating it, just show if the publisher has it enabled and let the market decide.
- thenickdude 5y ago
  Yes, I'd love it if NPM would mark any package as insecure if it transitively depended on a developer that didn't use 2FA.
eyelidlessness 5y ago
IMO they—NPM especially—should also prevent publishing arbitrary packages where the source is accessible. In such cases, `npm publish` should be an authorization check and run your publish lifecycle to produce the package. It’s absolutely bonkers that an ecosystem where the vast majority of packages are permissively licensed allows those packages to be published with basically whatever the heck you want, completely independent of whatever you would find inspecting and building it yourself.
mnahkies 5y ago

ipnon 5y ago

This is the price of free code. If you don't read the open source you're adding to your system then don't complain when it owns you! You wouldn't take your medicine without reading the label first. NPM is a miracle for open software development, but it requires diligence.

trog 5y ago
Weird comparison. The equivalent with medicine is not 'reading the label', but understanding the chemistry, reading all the research, reading all the associated papers, understanding all the biology, etc. It's reduced to you needing to only read the label by regulation. Expecting people to read the source of their dependencies, outside of very specific use cases and industries, is a lost cause.
- shukantpal 5y ago
  The difference is that NPM packages are provided for free.
  - Zababa 5y ago
    Many drugs are free or almost free where I live. Well, not really free, they're paid by our taxes. And npm is paid by Microsoft not paying theirs. So the difference isn't so big.
    - shukantpal 5y ago
      "And npm is paid by Microsoft not paying theirs." LOL ok.
- maccolgan 5y ago
  Imagine if you needed a doctoral degree and a billion dollar FDA study before being able to publish open source code.
LinuxBender 5y ago
Unless these are compiled binaries it should be fairly easy to spot funny-business. Surely someone out there must do diffs on version updates to see what changed. I know that I am nosey enough to see what changes people made rather than relying on change logs. Either way it would be nice if NPM devs signed their scripts. Nothing as complex as rpm/deb packages, just corresponding .asc files might be useful for the small handful of people that validate signatures. Or if public key management is a PITA and too much friction, then even a signed manifest file on a trusted origin server vs. mirrors could be super handy. The code deployment systems could curl the manifest and at least validate the checksums of the files.

alienalp 5y ago

For packages that popular, authority of more than one people should required or at least some kind of delay until npm update/install command catch it unless specifically that version set. If i remember correctly if someone hijacked my npm account and published something i wouldn't even noticed it. Obviously publisher should get an email or maybe even sms.

8organicbits 5y ago
The delay idea sounds promising. I'd want that as part of npm, but I suppose someone could build an NPM proxy that adds the delay. Has anyone tried something like this, even for a different ecosystem?
- seniorsassycat 5y ago
  It's possible with AWS CodeArtifact using EventBridge to promote after a delay. The company I work for has a three day delay on npm.
okhobb 5y ago
A large part of npm's staggering success is the very low friction to publish packages. I worry that any mitigation that slows down the publishing side of things would kill innovation in the ecosystem.
- 8organicbits 5y ago
  I imagined an optional delay for npm install/update. That way it would only slow down users who wanted more time.
  - alienalp 5y ago
    It makes so much sense, surprised me that it doesn't exist.
  - okhobb 5y ago
    Got it. Yea I agree that's useful and easy mitigation, and I'm sure enterprise users would certainly pay for other safety labeling/filtering/signing of packages.

eemax 5y ago

We pin all of our npm dependencies and upgrade them via dependabot. Dependabot links to the GitHub or GitLab release for each dependency bump, and I typically skim / scan every single commit to each dependency. But there's no guarantee that what's on GH matches what is uploaded to npm (which is what happened in this case; there are no malicious commits). Does anyone know of a good way to verify that a npm release matches what's on GH? Version controlling the entirety of node_modules/ and running untrusted updates in a sandbox would work in theory, but in practice many packages contain minified js which makes the diffs between version bumps unreadable.

pwdisswordfish0 5y ago
Skip the nonsense and just check your dependencies in directly to your repo. The separation has no real world gains for developers and doesn't serve anyone except the host of your source repo. As it turns out most people's repo host is also the operator of the package registry they're using, so there aren't even theoretical gains for them, either. Doing it this way doesn't preclude the ability to upgrade your dependencies, it _completely_ sidesteps the intentional or unintentional desync between a dependency's source and its releases, it means people have to go out of their way to get a deployment that isn't reproducible, and in 4 years when your project has rotted and someone tries to stand it up again even if just temporarily to effect some long-term migration, then they aren't going to run into problems because the packages and package manager changed out from beneath them. I run into this crap all the time to the point that people who claim it isn't a problem I know have to be lying.
- ncallaway 5y ago
  > I run into this crap all the time to the point that people who claim it isn't a problem I know have to be lying. I don't think that's right. Just because someone denies a problem exists—a problem that you know for a fact, with 100% certainty exists—doesn't mean they're lying. It may mean you know they are wrong, but wrong != lying, and it's a good thing to keep in mind. If you have external reasons to believe that the person you're talking to should or does know better, then it's fair to say they are lying. But, in general, if you accuse someone who is simply wrong to be lying, you're going to immediately shut down any productive conversation that you could otherwise have.

schleck8 5y ago

This appears to affect other popular packages as well, e.g. fbjs. It‘s time for proper supply chain security, the typo- and namesquatting minefield that is Pypi shows clearly why there is a need. Way too easy to distribute malware this way or register repos for popular packages by appending a version number for example. I‘m constantly running into shady deserted packages. Why not partnering with a large security vendor? The infrastructure is often provided as a donation from cloud providers as well

gnu8 5y ago

I don't know why anyone would auto-download untrusted packages as part of their own build/release chain and not review the code manually. Anything could be in there. The way people use NPM is pure fucking insanity.

austincheney 5y ago
Convenience and invented here syndrome. https://en.m.wikipedia.org/wiki/Invented_here https://en.m.wikipedia.org/wiki/Invented_here
Aeolun 5y ago
I mean, the alternative is reviewing 3000 packages by hand. No thanks. I’ll trust Snyk to let me know if anything is compromised.
- junon 5y ago
  Snyk is okay but I've had my issues with them. Never put all of your eggs in one basket.
  - ranguna 5y ago
    Could you elaborate on those issues ?
- gnu8 5y ago
  I suspect a huge fraction of those packages need to be rolled up into a standard library for which some foundation can take money and do proper release engineering.
  - qudat 5y ago
    But then aren’t you still trusting a third-party to properly audit their own code and ensure it doesn’t get compromised? Where’s the line?
    - 5y ago

tppiotrowski 5y ago

“ I noticed something unusual when my email was suddenly flooded by spams from hundreds of websites (maybe so I don't realize something was up, luckily the effect is quite the contrary).” I’ve been running a small deal aggregation and notification website for 15 years. Almost no new users these days. A few months ago I was excited to see dozens of new accounts created each day but no one ever clicked the verification link that was sent to their email. That’s when I first learned that creating unused accounts is a technique used by hackers to flood people’s inboxes to hide fraudulent purchases or other nefarious activity like publishing a hijacked npm package. A simple what is x + y? captcha solved the issue.

eyelidlessness 5y ago

There is an open NPM “audit assertions”[1] RFC which would allow the compromised package to be nested one dependency deeper, and would allow the hijacked ua-parser-JS package to assert that it’s unaffected. Should this proposal go through, it’s quite possible this would have gone much further. It would have allowed the attacker to wait for detection, and to silence any propagation of that to users of the otherwise legitimate package. I had to bow out of the conversation because I didn’t feel like I could engage it in a healthy way—I’m way too personally affected by my own experience dealing with dismissal of serious security issues—but I think folks here might be interested in it given this compromise. 1: https://github.com/npm/rfcs/pull/422 https://github.com/npm/rfcs/pull/422

ComputerGuru 5y ago
Wow. That takes the lax attitude towards security in the NPM world to a whole new level.
- eyelidlessness 5y ago
  To be fair to the proposal’s advocates and the person who posted the blog article which prompted it: they’re not wrong that npm audit is mostly irrelevant noise and actively harmful (incentivizes individuals to ignore meaningful security issues) because of that. Their proposal is just the wrong solution, and last I checked in they were too wedded to it.
- oefrha 5y ago
  npm audit is pretty damn meaningless at the moment. Creating a bog-standard react app with create-react-app (`npx create-react-app my-app`) right now results in > 68 vulnerabilities (21 moderate, 45 high, 2 critical) Even installing the latest npm itself (`npm install -g npm@8.1.1`) results in > 3 moderate severity vulnerabilities
  - bjornstar 5y ago
    create-react-app made their own security problems by bringing in the entire world, npm audit just makes that clear. npm itself having vulnerabilities is a more serious problem and it's not clear that they're taking it seriously.

ComputerGuru 5y ago

Why is this a link to Reddit? Usually that’s when the link is to the specific Reddit discussion because that’s what is being shared, but that’s not the case here. @mods I think the link should be to the actual post here: https://github.com/faisalman/ua-parser-js/issues/536 https://github.com/faisalman/ua-parser-js/issues/536

paxys 5y ago

I wish NPM had an option to disallow pulling dependencies from accounts that don’t use 2FA. Even if you trust a publisher it is so easy for their packages to get compromised because they are lax about security.

ievans 5y ago

Our approach to solving this on our open source project: 1. Enforce use of lock files 2. On any PR that changes any hash in the lock file, run a static analysis that looks for “permission” changes in any source file. E.g., used network, used env vars, used filesystem 3. Comment on the PR with any observed permission changes It is very alpha-quality and not yet generally available but here are some details: https://deps.semgrep.dev/ https://deps.semgrep.dev/

Osiris 5y ago
An unfortunate side-effect of this type of system, in my experience, is that you end up being stuck on very old dependencies for a very long time. When a security issue is discovered, perhaps months or years later, it is extremely difficult to upgrade because 1) the patch will always be applied to the most current release, which could be many major versions beyond what you run, and 2) manually backporting the security fix is impossible without creating your own fork and the code will likely be so different as to not be able to cleanly apply the patch. You are creating so much friction to update dependencies that you will find yourself unable to update them in the future. Small example: I recently upgraded a dependency that required us to move from node 12 to node 14. That required us to upgrade more packages, including our database ORM. The ORM was 2 years out of date. Now we have changes that literally affect the entire application and require significant regression testing (automated and manual) because the risk surface is so much larger. This wouldn't have happened if we didn't use a lock file with pinned versions. ------ In the past (node 4.x), lock files weren't written by default, and I (on a small project) had sufficient test coverage that always allowed NPM to install the latest minor version bump of every package, every time. If there was a problem caught by the tests, then I immediately fixed the issue with the upgrade. The nice thing about this is that I was always on the latest version of every dependency, so I always had the latest security fixes, and the online docs for the dependencies were always accurate to what I was using. If this particular exploit happened, it would have been more likely to get deployed but it would have also automatically gotten fixed as soon as the patch update rolled around. Whereas with a lock file, someone may have updated it and then not been aware when the "fixed" version came out because npm/yarn don't tell you that. As a JavaScript dev (full stack) I think lock files are a bad idea by making us LESS secure, not more (keeping around insecure older dependencies that can't be patched).

intruder 5y ago

I was actually about to use this package last week. Damn what a timing.

roofwellhams 5y ago

- steals cookies and browser data on windows: this means your browser cookies and all logged in accounts might be compromised. Maybe even passwords saved in browser. I'd even extend to password manager extensions. - crypto miner on both platforms - maybe: changes registry for existing crypto miners

godmode2019 5y ago

This is what I don't like about JS world. I started a project in react and it installed like 100+ random packages. I had to audit everyone, so silly not to have a standard library.

ranguna 5y ago
You want a standard library for... React? What about the people that like Vue or angular more than react?
- HamburgerEmoji 5y ago
  I think the suggestion was that there's this crazy explosion of transitive dependencies because JS is not 'batteries included' with some standard library that covers quite a lot of what people want. If there's no standard library, you have to include some libraries to do what you want. Those libraries had no standard library to depend on either, so they had to do the same thing you did. And so on.

crehn 5y ago

The JavaScript culture around dependencies is baffling to me. The simplest of tools will easily have hundreds of transitive dependencies, making these sort of events a mess to deal with, and causing the blast radius to be avoidably large.

userbinator 5y ago
Left-pad was already a warning sign that something is seriously wrong with the culture. https://news.ycombinator.com/item?id=11348798 https://news.ycombinator.com/item?id=11348798
- Zababa 5y ago
  The worst thing about it is that now left-pad is in the standard (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/padStart https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...), but that's it. is-odd has more than 400k weekly downloads https://www.npmjs.com/package/is-odd https://www.npmjs.com/package/is-odd.
  - imtringued 5y ago
    https://github.com/helpers/handlebars-helpers/issues/315 https://github.com/helpers/handlebars-helpers/issues/315 This is the only package that even uses (is even includes is odd) it while having more than 10 weekly downloads.
GordonS 5y ago
IMO this is largely a side effect of the JavaScript standard library being so anaemic - if available functions were bolstered significantly, it would eventually have some impact on this madness.

Ros2 5y ago

Semi-related: Microsoft is going to be (or has begun) checking for differences between published npm packages and their source control. I got a PR in my repository a few days ago leading back to a team trying to make it easier for packages to be reproducible from source https://github.com/microsoft/Secure-Supply-Chain https://github.com/microsoft/Secure-Supply-Chain

mnahkies 5y ago
How will this work with say typescript? It's pretty common to not commit the transpiled code - do you expect this to change, or would this check basically do a build + pack and then compare?
- Ros2 5y ago
  Yes it will have to do that. Some packages .npmignore the source files so those may not even be present. But doing that is actually easier than having to deal with all the different ways of versioning packages. For example, I am not using git tags in my project, some others may be, some may be using a branch not named `master` to deploy from. They're going to have to intelligently traverse the git tree to draw meaningful conclusions.

Zababa 5y ago

I'd encourage everyone to try the npm fund command (https://docs.npmjs.com/cli/v7/commands/npm-fund https://docs.npmjs.com/cli/v7/commands/npm-fund) on their repos to see how many projects need funding. All of these projects are an opportunity for a malicious actor to offer a lump sum of money to get the package.

knadh 5y ago

That the package is downloaded 7 million times a week exacerbates the impact significantly. The CI/CD trend of pulling everything from upstream over and over for builds (despite caching, as the absurd NPM download counts indicate) ensures that any upstream issue is distributed widely and frequently. Continuous Integration and Continuous Deployment of vulnerabilities.

technion 5y ago

I'm usually pretty critical of tiny NPM modules, but I really want to support whoever maintains this package. Hundreds of lines of regexes, people asking about IE8 support, and a constantly moving target every time a browser changes something. This really must be a horrible package to maintain.

rudian 5y ago
That’s their own fault. No one needs to “detect” random esoteric browsers. Once you have 4/5 detections you should be good. IE8’s UA hasn’t changed in forever, so you could just copy-paste one of the many regexes online and keep it unchanged.

darepublic 5y ago

A stupid dependency for user agent parsing.. just becoming more and more disillusioned with the js ecosystem. And then this. And at work the junior devs turning to random npm packages for every little thing.