Live data from Hacker News

Malicious crossenv package on npm

twitter.com

171–180 of 237 posts

Re: Malicious crossenv package on npm

#171
post #55
post #37

Earlier quoted context omitted.

Not really different from any other typo-squatting (e.g. domains).

Except that in this case you're installing software on your computer, not just visiting a webpage.

You might also be downloading the software from a webpage. ;)

Re: Malicious crossenv package on npm

#172
post #31

Friendly reminder, every time this happens... https://github.com/npm/npm/pull/4016 "However, this is just a piece of an overall solution, and it brings with it a lot of the baggage that comes along whenever GnuPG or PGP get involved. Without a web of trust (sigh), a PKI (ugh), or some other mechanism to tie identities to trust metrics, this is essentially a complicated, very expensive, and fragile version of the shas…

> insults two legends in crypto

Who?

Re: Malicious crossenv package on npm

#173

Earlier quoted context omitted.

Maven prevents this as well. To add a package to the global repository you need to show ownership of your namespace by posting your key, your website, your email, or most commonly these days your GitHub repo with identifying information. They do check to make sure you're allowed to use each package identifier. All package submissions are hand-curated, which should catch typosquatters. There's a clearly laid out patte…

Well npm requires you to login through their CLI in order to publish packages... The only difference is that you use a password instead of a key. No difference.

> Well npm requires you to login through their CLI in order to publish packages... The only difference is that you use a password instead of a key. No difference.

Yes, there is a difference, released must be digitally signed on maven. They are not on NPM, so a hacker can hijack your packages just by obtaining your npm credentials.

That's crypto 101 and you can't tell the difference?

Re: Malicious crossenv package on npm

#175
post #101
post #73

Earlier quoted context omitted.

I can explain how it can be done. Let's say you need a new dependency. You can't just add it to the project. Management would kill you. There's a lot of checks you have to make. Like licenses and signatures. In this case, you're concerned about signatures. I'll stick to that. If I believe I need crossenv, I see it advertises kent@doddsfamily.com as the author. I look up Kent Dodds. I find various bits of information…

One of the central problems of trust is that simple solutions don't scale well. Back in the day, one acquired a .com address by sending someone an email, because everyone knew everyone. cross-env has had 1.3 million downloads in the last month. How many of those "hey, I am evaluating your library" emails can Dodds field? Most node projects have hundreds of dependencies, if you include transitive dependencies. How man…

I suppose that to get an estimate of the number of actual users, you have to scale that number of downloads down by a factor of 10 - 1000, depending on if and what kind of dependency cache JS toolchains use (esp. around CI/CD).

But yeah, everyone contacing an author directly doesn't scale at all.

Re: Malicious crossenv package on npm

#176
post #142

Earlier quoted context omitted.

Maven does not have this problem. That package was just something you googled that hasn't been updated in two years because maven has required signed packages forever. My packages are all cryptographically signed with my private key. Maven doesn't just offer code signing, it's mandatory to deploy projects to the central repo. The automated package verifier will reject you if you don't have it. If someone gains access…

> That package was just something you googled that hasn't been updated in two years because maven has required signed packages forever. That something hasn't been updated in two years because it's feature complete and does what it's supposed to: verifies the integrity of dependencies for Signal [1]. > If someone gains access to my account and tries to modify my package without my private key it will not be accepted i…

Yes, this is important: Maven Central/Sonatype only checks if the submitted artifacts are signed (regardless of the used key).

The work is shifted to client, but there's currently no standardized way on how to verify dependencies and plugins.

There's an issue in the Maven bug tracker with the idea to extend the POM to allow trust information: https://issues.apache.org/jira/browse/MNG-6026

Re: Malicious crossenv package on npm

#177
In Crystal, we've decided that the dependency manager shards will have no centralised package repository, which we hope will solve problems like this. It makes forking shards very easy, it completely avoids name squatting, and it should help prevent typo squatting like this.

We also don't want shards to become yet another system package manager, used for installing executables to your PATH. Shards should never be run as root, unlike npm and pip.

Re: Malicious crossenv package on npm

#178
for every node package, see what node packages are 3 or less levenshtein distance away when it's uploaded, and go through all existing packages. Add an optional flag that will, if you try to install a package that has a package within that edit distance that is an order of magnitude more popular, give you warning and skip that package, an optional flag that errors, and a way to force it for a specific package. In the future, make the first optional flag the default, so people get warnings with instructions to override. Allow white listing of particular packages that may be problematic, and expect a shared white list Then, a year later after repeated warnings of the coming nodepocalypse, make the second optional flag the default, so if you haven't white listed or explicitly forced installing such a package, it will fail.

You will, of course break production for a few people who just didn't listen.

Alternatively, instead of edit distance, allow users to report problematic packages and do a similar thing. Do not provide a explicit award to users who report, so nobody would create fake malware just to report it.

In both cases, either implicitly or explicitly you are using the wisdom of the crowd to figure out the bad packages.

Re: Malicious crossenv package on npm

#179

Earlier quoted context omitted.

Maven prevents this as well. To add a package to the global repository you need to show ownership of your namespace by posting your key, your website, your email, or most commonly these days your GitHub repo with identifying information. They do check to make sure you're allowed to use each package identifier. All package submissions are hand-curated, which should catch typosquatters. There's a clearly laid out patte…

Well npm requires you to login through their CLI in order to publish packages... The only difference is that you use a password instead of a key. No difference.

There's a huge difference. I could put my private key on a hardware dongle completely isolated from my PC environment if I wanted.

Npm is a public internet login with a password of your choosing, probably the most insecure form of authentication there is bar doing nothing. I could be brute forcing your login credentials right now and you wouldn't even know.

Also, users are safe even if maven itself is compromised because attackers still can't validate my private key. I don't think you could say the same about npm...

Post reply on HN