6 ms·

I don’t think it’s fair to single npm out here. The truth is any package manager that lets anyone publish package updates is vulnerable to this type of attack.

matthewbauer 7y ago
Semver probably makes the problem worse though.
- wheelerwj 7y ago
  how?
  - matthewbauer 7y ago
    Dependency ranges mean package updates happen automatically. So a minor release could contain malicious code without anyone noticing. I still think semver is worthwhile even if it a little bit more vulnerable to this kind of attack.
    - solidasparagus 7y ago
      Yeah, but a dependency attack is a rarer issue than out-of-date dependencies that contain known security vulnerabilities.
  - pdpi 7y ago
    Because if you don't consider SemVer as part of your threat model, you'll specify "v1.2.3 or above" instead of "v1.2.3".
SanchoPanda 7y ago
NPM isn't being singled out as part of a hypothetical risk analysis, this is about an attack that actually happened via NPM.
dtech 7y ago
npm encourages an auto-upgrading versioning scheme: take version x or higher. It's great for keeping dependencies up-to-date, but this makes it immensely vulnerable to the kind of malware injection, as publishing a library version with payload will immediately propagate throughout the ecosystem. In most other version managers (e.g. maven) every library and application specifies a hard-coded version, which requires users to manually upgrade, giving a window were a malicious version can be detected before it affects anyone.
- cortesoft 7y ago
  In this case, though, someone explicitly changed the included version to the malicious one.
- nullandvoid 7y ago
  For a security critical app not locking down the dependencies to audited versions seems very dangerous indeed and I believe there is some blame to be had there
  - matthewbauer 7y ago
    You’re still vulnerable if you lock down dependencies during the period the malicious code is wild though. You have to actually audit your locked dependencies to consider yourself safe.
    - undecisive 7y ago
      Isn't that expecting the car to be invented before the wheel? From what I've seen, quite a few of these have been targetted attacks - the assailants have targetted specific variables that existed in a specific codebase that they knew imports their module. Of course, if you've only just started writing that codebase, your dependencies have no way of knowing where you're storing private keys (short of somehow scanning the object space for variable names like "private_key") But yes, in theory I would love for any *-sensitive code to go through a thorough audit after every dependency update before a version gets released in the wild. I'm guessing that next-to-nobody has the resources for that kind of an effort though.
GordonS 7y ago
NPM has, specifically and deliberately, played down the successful theft here, making out that they completely foiled it. If they hadn't done such a scummy, corporate spin job on this, I'd be inclined to agree with you - but they did.

matthewbauer 7y ago

Semver probably makes the problem worse though.

wheelerwj 7y ago
how?
- matthewbauer 7y ago
  Dependency ranges mean package updates happen automatically. So a minor release could contain malicious code without anyone noticing. I still think semver is worthwhile even if it a little bit more vulnerable to this kind of attack.
  - solidasparagus 7y ago
    Yeah, but a dependency attack is a rarer issue than out-of-date dependencies that contain known security vulnerabilities.
- pdpi 7y ago
  Because if you don't consider SemVer as part of your threat model, you'll specify "v1.2.3 or above" instead of "v1.2.3".

SanchoPanda 7y ago

NPM isn't being singled out as part of a hypothetical risk analysis, this is about an attack that actually happened via NPM.

dtech 7y ago

npm encourages an auto-upgrading versioning scheme: take version x or higher. It's great for keeping dependencies up-to-date, but this makes it immensely vulnerable to the kind of malware injection, as publishing a library version with payload will immediately propagate throughout the ecosystem. In most other version managers (e.g. maven) every library and application specifies a hard-coded version, which requires users to manually upgrade, giving a window were a malicious version can be detected before it affects anyone.

cortesoft 7y ago
In this case, though, someone explicitly changed the included version to the malicious one.
nullandvoid 7y ago
For a security critical app not locking down the dependencies to audited versions seems very dangerous indeed and I believe there is some blame to be had there
- matthewbauer 7y ago
  You’re still vulnerable if you lock down dependencies during the period the malicious code is wild though. You have to actually audit your locked dependencies to consider yourself safe.
  - undecisive 7y ago
    Isn't that expecting the car to be invented before the wheel? From what I've seen, quite a few of these have been targetted attacks - the assailants have targetted specific variables that existed in a specific codebase that they knew imports their module. Of course, if you've only just started writing that codebase, your dependencies have no way of knowing where you're storing private keys (short of somehow scanning the object space for variable names like "private_key") But yes, in theory I would love for any *-sensitive code to go through a thorough audit after every dependency update before a version gets released in the wild. I'm guessing that next-to-nobody has the resources for that kind of an effort though.

GordonS 7y ago

NPM has, specifically and deliberately, played down the successful theft here, making out that they completely foiled it. If they hadn't done such a scummy, corporate spin job on this, I'd be inclined to agree with you - but they did.