4 ms·

Its not a bad idea, might help in certain cases. But the real solution to this kind of attack is to stop resolving packages by name and instead resolve them by

Its not a bad idea, might help in certain cases. But the real solution to this kind of attack is to stop resolving packages by name and instead resolve them by hash, then binding a name to that hash for local use. That would of course be a whole different, mostly unexplored, world, but there's just no getting around the fact that blindly accepting updated versions of something based on its name is always going to create juicy attack surface around the resolution of that name to some bits.

mirekrusin 1y ago
name + version are immutable, you can't republish packages in npm under existing version. you can only unpublish. content hash integrity is verified in lockfiles. the problem is with dependencies using semver ranges, especially wide ones like "debug": "*" initiatives like provenance statements [0] / code signing are also good complement to delayed dependency updates. also not running as default / whitelisting postinstall scripts is good default in pnpm. modifying (especially adding) keys in npmjs.org should be behind dedicated 2fa (as well as changing 2fa) [0] https://docs.npmjs.com/generating-provenance-statements https://docs.npmjs.com/generating-provenance-statements
- __MatrixMan__ 1y ago
  Those are promises that npm intends to keep, but whether they do or not isn't something that you as a package user can verify. Plus there's also the possibility that the server you got those bits from was merely masquerading as npm. The only immutability that counts is immutability that you can verify, which brings us back to cryptographic hashes.
  - mirekrusin 1y ago
    ...which are already present in lockfiles, available in registry ie. https://registry.npmjs.org/debug https://registry.npmjs.org/debug etc. - it's not a problem.
frankdejonge 1y ago
Resolving by hash is a half solution at best. Not having automated dependency upgrades also has severe security downsides. Apart from that, lock files basically already do what you describe, they contain the hashes and the resolution is based off the name while the hash ensures for the integrity of the resolved package. The problem is upgrade automation and supply chain scanning. The biggest issue there is that scanning is not done where the vulnerability is introduced because there is no money for it.
- __MatrixMan__ 1y ago
  Do you suppose that automated dependency upgrades are less likely to introduce malicious code than to remove it? They're about compliance, not security. If I can get you to use malicious code in the first place I can also trick you into upgrading from safe code to the vulnerable code in the name of "security". As for lock files, they prevent skulduggery after the maintainer has said "yeah, I trust this thing and my users should too" but the attacks we're seeing is upstream of that point because maintainers are auto-trusting things based on their name+version pair, not based on their contents.
  - debazel 1y ago
    > If I can get you to use malicious code in the first place I can also trick you into upgrading from safe code to the vulnerable code in the name of "security". Isn't the whole point that malicious actors usually only have a very short window where they can actually get you to install anything, before shut out again? That's the whole point of having a delay in the package-manager.
    - __MatrixMan__ 1y ago
      Who is going to discover it in that time? Not the maintainers, they've already released it. Their window for scrutiny has passed. There is some sense in giving the early adopters some time to raise the alarm and opting into late adoption, but isn't that better handled by defensive use of semantic versioning? Consider the xzutils backdoor. It was introduced a month before it was discovered, and it was discovered by a user. If that user had waited a few days, it would just have been discovered a few days later, during which time it may have been added to an even wider scope of downstream packages. That is, supposing they didn't apply reduced scrutiny due to their perception that it was safe due to the soak period. Its not nothing, but its susceptible to creating a false sense of security.
mort96 1y ago
The problem here isn't, "someone introduced malware into an existing version of a package". The problem is, "people want to stay up to date, so when a new patch version is released, everyone upgrades to that new patch version".
- __MatrixMan__ 1y ago
  The problem is that they implicitly do so. If they had to enter the hash of the latest and greatest version, the onus would be on them at that time to scrutinize it. At worst the spread of the malicious package would be slowed, and at best it would be stopped.
  - mort96 1y ago
    Surely you'd achieve the same thing by making people manually enter a new version number? I'm not inherently against the idea of specifying a hash, it would protect against NPM hosting infrastructure being compromised, but again, that's not what we're seeing here
    - __MatrixMan__ 1y ago
      If you end up with bits that hash to 0xabc123 and I end up with bits that hash to 0x456def and we both think we installed fooapp version 7.8.9, there's nothing about the version number that tells us which one of us has been hacked. But if we both attempt to install 0x456def, it's clear that whoever has 0xabc123 is in trouble. This is especially important in cases where you might need a package while you're on a separate network partition than npm. Any peer can provide it and you know it hasn't been tampered with because if it had been it would have a different hash.
      - mort96 1y ago
        > If you end up with bits that hash to 0xabc123 and I end up with bits that hash to 0x456def and we both think we installed fooapp version 7.8.9, there's nothing about the version number that tells us which one of us has been hacked. If this happens, then either the NPM registry has been compromised or my system's 'npm' program or your system's 'npm' program has been compromised. If the discrepancy is due to one of us running a malicious 'npm', then that malicious 'npm' CLI program could've just not flagged the signature mismatch, so specifying a hash doesn't help us anything. If both of us are using a non-compromised 'npm' program, and the NPM registry isn't compromised, then we will never be in a situation where my "fooapp version 7.8.9" and your "fooapp version 7.8.9" differs. If a malicious actor compromises an account with publish access for the fooapp package, then all the malicious actor can do is publish a new "fooapp version 7.8.10" that has malware. That's what has happened in every single one of these high profile NPM hacks. You can't retroactively change old versions of your own packages. So to protect against this kind of attack (which, again, means every single NPM hack to date), just not auto-upgrading between minor versions is enough. To protect against a compromised NPM registry, I agree that we should have package checksums living in our git repositories. But NPM already has that: the package-lock.json contains checksums. I don't understand what it would give us to have that checksum in the package.json instead of the package-lock.json.

mirekrusin 1y ago

name + version are immutable, you can't republish packages in npm under existing version. you can only unpublish. content hash integrity is verified in lockfiles. the problem is with dependencies using semver ranges, especially wide ones like "debug": "*" initiatives like provenance statements [0] / code signing are also good complement to delayed dependency updates. also not running as default / whitelisting postinstall scripts is good default in pnpm. modifying (especially adding) keys in npmjs.org should be behind dedicated 2fa (as well as changing 2fa) [0] https://docs.npmjs.com/generating-provenance-statements https://docs.npmjs.com/generating-provenance-statements

__MatrixMan__ 1y ago
Those are promises that npm intends to keep, but whether they do or not isn't something that you as a package user can verify. Plus there's also the possibility that the server you got those bits from was merely masquerading as npm. The only immutability that counts is immutability that you can verify, which brings us back to cryptographic hashes.
- mirekrusin 1y ago
  ...which are already present in lockfiles, available in registry ie. https://registry.npmjs.org/debug https://registry.npmjs.org/debug etc. - it's not a problem.

frankdejonge 1y ago

Resolving by hash is a half solution at best. Not having automated dependency upgrades also has severe security downsides. Apart from that, lock files basically already do what you describe, they contain the hashes and the resolution is based off the name while the hash ensures for the integrity of the resolved package. The problem is upgrade automation and supply chain scanning. The biggest issue there is that scanning is not done where the vulnerability is introduced because there is no money for it.

__MatrixMan__ 1y ago
Do you suppose that automated dependency upgrades are less likely to introduce malicious code than to remove it? They're about compliance, not security. If I can get you to use malicious code in the first place I can also trick you into upgrading from safe code to the vulnerable code in the name of "security". As for lock files, they prevent skulduggery after the maintainer has said "yeah, I trust this thing and my users should too" but the attacks we're seeing is upstream of that point because maintainers are auto-trusting things based on their name+version pair, not based on their contents.
- debazel 1y ago
  > If I can get you to use malicious code in the first place I can also trick you into upgrading from safe code to the vulnerable code in the name of "security". Isn't the whole point that malicious actors usually only have a very short window where they can actually get you to install anything, before shut out again? That's the whole point of having a delay in the package-manager.
  - __MatrixMan__ 1y ago
    Who is going to discover it in that time? Not the maintainers, they've already released it. Their window for scrutiny has passed. There is some sense in giving the early adopters some time to raise the alarm and opting into late adoption, but isn't that better handled by defensive use of semantic versioning? Consider the xzutils backdoor. It was introduced a month before it was discovered, and it was discovered by a user. If that user had waited a few days, it would just have been discovered a few days later, during which time it may have been added to an even wider scope of downstream packages. That is, supposing they didn't apply reduced scrutiny due to their perception that it was safe due to the soak period. Its not nothing, but its susceptible to creating a false sense of security.

mort96 1y ago

The problem here isn't, "someone introduced malware into an existing version of a package". The problem is, "people want to stay up to date, so when a new patch version is released, everyone upgrades to that new patch version".

__MatrixMan__ 1y ago
The problem is that they implicitly do so. If they had to enter the hash of the latest and greatest version, the onus would be on them at that time to scrutinize it. At worst the spread of the malicious package would be slowed, and at best it would be stopped.
- mort96 1y ago
  Surely you'd achieve the same thing by making people manually enter a new version number? I'm not inherently against the idea of specifying a hash, it would protect against NPM hosting infrastructure being compromised, but again, that's not what we're seeing here
  - __MatrixMan__ 1y ago
    If you end up with bits that hash to 0xabc123 and I end up with bits that hash to 0x456def and we both think we installed fooapp version 7.8.9, there's nothing about the version number that tells us which one of us has been hacked. But if we both attempt to install 0x456def, it's clear that whoever has 0xabc123 is in trouble. This is especially important in cases where you might need a package while you're on a separate network partition than npm. Any peer can provide it and you know it hasn't been tampered with because if it had been it would have a different hash.
    - mort96 1y ago
      > If you end up with bits that hash to 0xabc123 and I end up with bits that hash to 0x456def and we both think we installed fooapp version 7.8.9, there's nothing about the version number that tells us which one of us has been hacked. If this happens, then either the NPM registry has been compromised or my system's 'npm' program or your system's 'npm' program has been compromised. If the discrepancy is due to one of us running a malicious 'npm', then that malicious 'npm' CLI program could've just not flagged the signature mismatch, so specifying a hash doesn't help us anything. If both of us are using a non-compromised 'npm' program, and the NPM registry isn't compromised, then we will never be in a situation where my "fooapp version 7.8.9" and your "fooapp version 7.8.9" differs. If a malicious actor compromises an account with publish access for the fooapp package, then all the malicious actor can do is publish a new "fooapp version 7.8.10" that has malware. That's what has happened in every single one of these high profile NPM hacks. You can't retroactively change old versions of your own packages. So to protect against this kind of attack (which, again, means every single NPM hack to date), just not auto-upgrading between minor versions is enough. To protect against a compromised NPM registry, I agree that we should have package checksums living in our git repositories. But NPM already has that: the package-lock.json contains checksums. I don't understand what it would give us to have that checksum in the package.json instead of the package-lock.json.