Question, since I don't use much node.js. Doesn't the repository publish GPG-signing and a checksum hash of every file? The compromised package should have been rejected by the retrieval tool, no?
There was once a PR open, but it was rejected after sitting idle for over a year.
Yes, you read that right.
Yes, it doesn't solve all the problems and yes you still have to determine who to trust, but at least it makes it POSSIBLE to trust anything. Currently it's impossible to trust anything that you install—and packages can run arbitrary, unsandboxed code with access to the full filesystem when they are installed. That just seems insane to me.
Alice installs malicious eslint.
Attacker has control of Alice's machine and signs a malicious version of Alice's package using Alice's key.
Attacker publishes a new version of Alice's package.
Bob installs Alice's (malicious) package.
Attacker has control of Bob's machine and signs a malicious version of Bob's package using Bob's key.
Attacker publishes a new version of Bob's package.
...repeat
Building a system that is immune against the maintainer's device being compromised puts you into "Reflections on trusting trust" territory. Just sticking two-factor authentication into that process won't change much (though it would of course also mitigate the password reuse vector).
Yegge's security vs accessibility rant/monograph should be required reading. The NPM team's choice to favor accessibility is a reasonable choice. The trade-offs are significant.
https://eslint.org/blog/2018/07/postmortem-for-malicious-pac...
The account of one of the eslint maintainers was compromised.
A ledger of hashes of published packages that is run on separate infrastructure and consumed by the client would do just as well as signing for detection of both threats without a lot of complicated issues around third party key material handling, crypto library bugs, and the need for revocation processes.
Note: this is based on experience validating all gems after the yaml scare years ago.
Clicking your heels three times and saying 'GPG', of course, doesn't fix much.
What you advocate in this thread is setting aside defense in depth. Could the attacker have used the stolen credentials to pivot to other machines and ultimately gain access to the GPG keys? Maybe, but it's a hurdle, and not a small one. The more hurdles we can place in the way, the less likely it is that small mistakes cascade into total system failure.
There may be legitimate reasons to not to use package signing, but this is definitely not one of them.
>2018-07-12 18:42 UTC: npm revoked all access tokens generated before 2018-07-12 12:30 UTC.
Does this mean that potentially any version update (of ANY npm package) published between 9:49 and 18:42 could potentially be compromised? Someone's going to have to go through all of them with a fine tooth comb...
The maintainer whose account was compromised had reused their npm password on several other sites and did not have two-factor authentication enabled on their npm account.
I wonder how many accounts the attacker checked before hitting this account. This will definitely get a nice place in the bucket of examples I throw to people, when I see they are still reusing passwords.