Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Malicious crossenv package on npm

twitter.com

Post reply on HN
Print view View original

181–190 of 237 posts

Re: Malicious crossenv package on npm

#181

Post by lmm »

KirinDave wrote: post #77
danjoc wrote: 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…

Hashes already exist. The problem is not a lack of integrity verification. We have that. The problem is not a lack of identity verification, we haven't really shown that NPM is lacking for that. The problem is one of addressing. People want to get packages by a utf8 and natural language string, followed by a version boundary check. If people referred to packages by their proper hash (as one does when referencing valu…

> If people referred to packages by their proper hash (as one does when referencing values from IPFS), then we wouldn't have this problem. If people had a public key and added a key fingerprint that would also work, but would not provide any additional verification to the code (1).

The hash naturally changes with every release. The key fingerprint doesn't. Updating your dependencies to new releases is much, much more frequent than adding a new dependency; people are willing to put more effort into the latter than the former.

> You aren't even in Keybase. Have you personally participated in any keysigning parties? Can I find your public key details here?

Keybase encourages poor practices and as such I avoid it. But I've been to keysigning parties and my key's details are published any number of places. (Since adding one more is all to the good, the fingerprint is 400A C7D2 E7A1 802A AE2C C459 B1E5 712A 6D03 3D61)

Re: Malicious crossenv package on npm

#182

Post by lmm »

hedora wrote: post #105
slackingoff2017 wrote: post #56

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…

Does maven really reliably validate packages these days? I once did a mvn build on a southwest flight and got stuff like "Syntax error: Click here for free TV..." all over my console. This was ~4 years ago. If I remember right, maven "supported" package validation, but it was certainly not the de facto standard.

The repository enforces it. The client doesn't check by default which is a poor default, but at least checking is possible for those who care.

Re: Malicious crossenv package on npm

#183

Post by pilif »

jnbiche wrote: post #65
iamakulov wrote: post #41

Earlier quoted context omitted.

npm is working on a solution for misspellings through: https://twitter.com/maybekatz/status/892501201551368192

They should first get package signatures implemented, it's a bigger threat to the npm community. At worst, the mispelled packages effect a handful of people who don't double check the package name for the package they're installing. If someone compromises the integrity of an ultra popular package, it threatens thousands, perhaps even millions of people (counting all people consuming the code downstream, ie users). An…

>They should first get package signatures implemented, it's a bigger threat to the npm community

Considering that signature checking would not have prevented this attack that has actually happened, I would say that not having signed packages is not in-fact the bigger threat.

Or can you point us to a prior example of a successful attack that could have been thwarted with proper signature checking?

Re: Malicious crossenv package on npm

#184

Post by pilif »

cyphar wrote: post #92
tomjakubowski wrote: post #72

Earlier quoted context omitted.

Requiring 2FA on publish would do just as well to prevent malicious actors from exploiting poor user passwords, and without imposing such a burden on developers. I don't have numbers, but it certainly seems like developers are more likely to maintain a set of TOTP key/epoch pairs than a PGP keypair. I guess that TOTP-based 2FA challenges would be annoying in the case where CI performs the "publish" step.

The problem is that users downloading the package can't verify that the developer used TOTP to publish. Really, it takes minimal effort to make and use a GPG key. You can write a fairly basic script to automate the signing of stuff as well. Here's an example (it even signs the source archive): https://github.com/openSUSE/umoci/blob/master/hack/release.s...

> can't verify that the developer used TOTP to publish

they can if npm enforces the usage of TOTP for publishing.

As a user who uses both a GPG key to sign commits and a 2FA token to authenticate to all sites where this is possible, I can assure you that dealing with TOTP token is more fun than dealing with GPG keys.

Re: Malicious crossenv package on npm

#185

Post by pilif »

boramalper wrote: post #171
db48x wrote: post #55

Earlier quoted context omitted.

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. ;)

That would still be a two-step process (downloading from the browser and then manually executing it).

`npm install` runs code as part of the initial step.

Also, `npm install foo` will of course not just run code from `foo` but from all its dependencies and their dependencies dependencies as well.

Re: Malicious crossenv package on npm

#186

Post by cyphar »

pilif wrote: post #184
cyphar wrote: post #92

Earlier quoted context omitted.

The problem is that users downloading the package can't verify that the developer used TOTP to publish. Really, it takes minimal effort to make and use a GPG key. You can write a fairly basic script to automate the signing of stuff as well. Here's an example (it even signs the source archive): https://github.com/openSUSE/umoci/blob/master/hack/release.s...

> can't verify that the developer used TOTP to publish they can if npm enforces the usage of TOTP for publishing. As a user who uses both a GPG key to sign commits and a 2FA token to authenticate to all sites where this is possible, I can assure you that dealing with TOTP token is more fun than dealing with GPG keys.

> they can if npm enforces the usage of TOTP for publishing.

So what is going to happen to all of the packages published before TOTP is turned on? Not to mention that there have been many cases where second-factors have been bypassed (even Google's authentication[1]). Which means I'm forced to trust that there are no exploits in NPM's authentication system, as opposed to trusting that PGP signatures are not broken. I know which one I would bet on.

As for dealing with PGP keys, come on. We all know that GPG's interfaces are bad for normal users, but all it takes to be able to sign things is:

  % gpg --generate-key
And answering the interactive prompts. There are many tools that wrap this functionality as well. Once you have a key you can just write a single script and then re-use it (I would expect that NPM would also publish said script to make it even easier). I'm sorry, but if you are trying to develop software for other people to depend on, I expect you to have enough technical literacy to be able to run two commands and read some documentation. It's really not that hard.

[1]: https://shubs.io/how-i-bypassed-2-factor-authentication-on-g...

Re: Malicious crossenv package on npm

#187

Post by nl »

notjack wrote: post #131
thehardsphere wrote: post #123

Earlier quoted context omitted.

Other programming ecosystems have solved these problems without these glaring problems, so I don't understand why you're acting as though this is unsolvable while requiring lots of money.

Other programming ecosystems are at least an order of magnitude smaller and not intrinsically tied to technology that's in relatively extreme flux with a massive amount of users (browsers).

least an order of magnitude smaller

No they aren't.

It's true that NPM is the biggest package repository by some way, but it's only ~2x the count of the Maven repository (492135 vs 194954). PHP and Ruby also have the same order of magnitude.

tied to technology that's in relatively extreme flux with a massive amount of users

Maven/Java has similar challenges to some extent with both Android and server side development being extremely common in the same language. The large number of users and the extreme technology flux is also similar.

Re: Malicious crossenv package on npm

#188

Post by TrickyRick »

slackingoff2017 wrote: post #133
KirinDave wrote: post #77

Earlier quoted context omitted.

Hashes already exist. The problem is not a lack of integrity verification. We have that. The problem is not a lack of identity verification, we haven't really shown that NPM is lacking for that. The problem is one of addressing. People want to get packages by a utf8 and natural language string, followed by a version boundary check. If people referred to packages by their proper hash (as one does when referencing valu…

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…

Actually Maven Central has about 200K packages. Incidentally about the same number of packages by which npm has increased in the last year. So no, a hand-curated submission process is probably not reasonable

[1]: http://www.modulecounts.com

Re: Malicious crossenv package on npm

#189

Post by DorothySim »

microtonal wrote: post #146
KirinDave wrote: post #128

Earlier quoted context omitted.

That's fine, but gpg signatures would do nothing to prevent this and widy scaled webs of trust don't exist.

Just signatures would indeed not help much in this particular case. Signatures plus other ways to establish trust will help. To give two examples: - macOS apps need to be signed (to run without extra work). The keypair is associated with a developer ID account that has a credit card on file. Abuse is still possible (stolen credit card, stolen certificate), but a lot harder. - Some open source project have their own W…

> For example, IIRC NetBSD required new developers to meet with one or two existing developers in person to verify their identity. (Pretty much like a regular PGP WoT.)

Debian also requires OpenPGP keys and WoT for all developers.

Re: Malicious crossenv package on npm

#190

Post by TrickyRick »

iamakulov wrote: post #41
danjoc wrote: 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…

npm is working on a solution for misspellings through: https://twitter.com/maybekatz/status/892501201551368192

Seems like they went completely overboard in terms of complexity. Why not have any camel/kebab/snake case reserve the same word in any type of casing? I.e. if I submit cross-env I also get crossenv, cross_env and crossEnv for free. Same goes if I submit any of the others (Exception of course being "crossenv" which only reserves "crossenv").
Post reply on HN