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

211–220 of 237 posts

Re: Malicious crossenv package on npm

#211

Post by KirinDave »

sloppycee wrote: post #205
KirinDave wrote: post #200

Earlier quoted context omitted.

> so a hacker can hijack your packages just by obtaining your npm credentials. Couldn't they 'just' steal your GPG key as well? If someone can trivially steal a strong password from you, I'd worry about key material as well. > That's crypto 101 and you can't tell the difference? Please reconsider sentences like these.

The issue is of who to trust, the package maintainer or the package repository? It is comparatively trivial to steal a strong password when it is transmitted over the internet vs local key material. Nation states with bad certs (china has done this) can steal your password, npm can steal your password, npm can be hacked and leak passwords, npm can be subject to a NSL and forced to hand over passwords, etc, etc. There…

> The issue is of who to trust, the package maintainer or the package repository?

Interesting framing.

> It is comparatively trivial to steal a strong password when it is transmitted over the internet vs local key material.

"Comparatively trivial?" I don't really understand this. I think you're suggesting that SSL cert attacks are easier than evil maid attacks due to this paragraph:

> Nation states with bad certs (china has done this) can steal your password, npm can steal your password, npm can be hacked and leak passwords, npm can be subject to a NSL and forced to hand over passwords, etc, etc.

Pardon me, but we're so far afield of the actual reality and the logistics that plague it that I decline to continue this conversation. If your adversary is nation states, you need a code audit (preferably several). You can't trust the signatures precisely because nation states are so well equipped to perform evil maid attacks.

It is 2017, evil maid attacks are the reality of the nation-state intelligence industry. We're seeing examples of them leaking out. They're in active use not just in a targetted mechanism, but speculatively! We have evidence intelligence agencies sell comprimised USB keys in bulk near the physical locations targets are likely to enter just to see if they can catch them in a moment of bad opsec.

Honestly this all feels like an attempt to say, "We should use GPG because it is good." Maybe it is. I'm not so sure, given the logistical reality.

But it wouldn't prevent the attack we see in the tweet above. It wouldn't make the root post of this thread correct. And I'm not sure it would accomplish what you're saying.

I'm sorry, I simply don't have time to chase this degree of abstracted hypothetical on a day old thread. I'm writing this final message here as a courtesy to those involved.

Re: Malicious crossenv package on npm

#212

Post by KirinDave »

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…

Apple doesn't have a web of trust. Microsoft and Google do not either. They bless your code for their marketplaces. Crypto is just coincidentally how they do it.

A web of trust implies transitive trust.

I'm pretty sure the same is true of Debian, but I don't know about the others. But these are NOT webs of trust.

What's more, other open source projects simply do not deal with the scale of NPM. The amount of data they move and offer is pretty brutal. Lots of dismissive engineers sneer at the javascript numeric tower and simply do not understand how difficult and perhaps even surprising the implementation of NPM as a platform is, given its scale.

Re: Malicious crossenv package on npm

#213

Post by KirinDave »

DorothySim wrote: post #189
microtonal wrote: post #146

Earlier quoted context omitted.

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.

What is WOT in this context? I thought Debian required that you register with them, not that there was some other trust threshold.

Re: Malicious crossenv package on npm

#214

Post by sloppycee »

KirinDave wrote: post #211
sloppycee wrote: post #205

Earlier quoted context omitted.

The issue is of who to trust, the package maintainer or the package repository? It is comparatively trivial to steal a strong password when it is transmitted over the internet vs local key material. Nation states with bad certs (china has done this) can steal your password, npm can steal your password, npm can be hacked and leak passwords, npm can be subject to a NSL and forced to hand over passwords, etc, etc. There…

> The issue is of who to trust, the package maintainer or the package repository? Interesting framing. > It is comparatively trivial to steal a strong password when it is transmitted over the internet vs local key material. "Comparatively trivial?" I don't really understand this. I think you're suggesting that SSL cert attacks are easier than evil maid attacks due to this paragraph: > Nation states with bad certs (ch…

Just consider: - China issues a bad cert for npm - Slurps up all passwords from Chinese maintainers en masse

Now we can't trust any package published from China.

This is a bigger deal than a targeted evil maid. Distributed trust is better than centralized trust.

Re: Malicious crossenv package on npm

#215

Post by nullstyle »

KirinDave wrote: post #202
unkown-unknowns wrote: post #164

Earlier quoted context omitted.

Like sibling says, doxxing implies that you'll post their personal info online. The problem does not lie in attacking bad people, the problem is that there is a high risk that you THINK you've identified who the bad actor is but actually the person you decide to "retaliate" against had nothing to do with what was done to you. That's why we leave law enforcement to the law enforcement officials and justice to the just…

> Like sibling says, doxxing implies that you'll post their personal info online. It's unfortunate that so many people don't know what the word means, because now we're redefining the word to a very specific and malicious definition that makes communication about nuances around the intersection of rights here more difficult. > there is a high risk that you THINK you've identified who the bad actor is but actually the…

> It's unfortunate that so many people don't know what the word means

Perhaps you can cite a history of the word, then maybe I'll trust your definition over some other.

You asked for clarification to avoid future misunderstanding and then proceed to reject our clarifications as if there's some nerd-word central authority that we're not aware of. We can't even agree on one 'x' or two.

Re: Malicious crossenv package on npm

#216

Post by graphememes »

KirinDave wrote: post #206
lmm wrote: post #181

Earlier quoted context omitted.

> 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…

I don't understand why you feel that the keybase question was directed at you. The decision to enter into this part of the discussion definitely hurt otherwise interesting post. It's true that a signature is based around a component with longer lifespan than a hash. However the management and trust of that component damages this argument severely. I am unaware of any web of trust in active use that could operate a np…

Because it was a direct reply to the individual. If used as an example you should give context, otherwise your comments are directed towards who you reply to.

Re: Malicious crossenv package on npm

#217

Post by orf »

raggi wrote: post #198
thehardsphere wrote: post #196

Earlier quoted context omitted.

Java/Maven.

So you use https://github.com/whispersystems/gradle-witness , and you manually verify everything you whitelist right? And you never typo, right?

I doubt he does, but i also doubt that installing a framework via maven brings in 1,000 implicit dependencies from 1,000 untrusted authors, unlike in JS land.

Edit: react, webpack, babel, babel-preset-env bring in 1,257 dependencies. Try vetting all those by hand.

Re: Malicious crossenv package on npm

#218

Post by tomc1985 »

KirinDave wrote: post #201
tomc1985 wrote: post #139

Earlier quoted context omitted.

Yeah I'm not really following how users desiring a natural-language tuple-looking thing prevents proper identity verification. Even without namespacing strong identity controls (signature verification and preventing unauthorized accounts from posting under a taken name, for example) can prevent most attacks short of typosquatting.

You seem to have a handle on every aspect of this situation except what the actual attack we're discussing was. It was typo squatting.

And you like to assume things.

Name canonicalization gets you part of the way there. But unless you want to go full-on namespacing then you must realize you are fighting a pointless battle.

You cannot reasonably expect to save users from themselves in every way.

Re: Malicious crossenv package on npm

#219

Post by thehardsphere »

raggi wrote: post #198
thehardsphere wrote: post #196

Earlier quoted context omitted.

Java/Maven.

So you use https://github.com/whispersystems/gradle-witness , and you manually verify everything you whitelist right? And you never typo, right?

0. What I do is irrelevant to whether or not the other people in the community have solved that problem. Which they have.

1. That's a Gradle plugin. I do not use Gradle. I use Maven.

2. I don't need to "manually verify everything I whitelist" (which is not exactly how Maven works but w/e) because everything in Central is cryptographically signed and can't be replaced simply because someone deleted all of their projects in a fit of pique, and some other person swooped in and used the exact same name.

3. I don't have to worry about typos, because I can't add a dependency to my project without editing the project's POM, so fat fingering on the command line cannot add random packages to the project. Plus, Maven artifacts are namespaced, so I would have to be pretty drunk to make so many typos that a different, existing package downloaded.

Re: Malicious crossenv package on npm

#220

Post by thehardsphere »

orf wrote: post #217
raggi wrote: post #198

Earlier quoted context omitted.

So you use https://github.com/whispersystems/gradle-witness , and you manually verify everything you whitelist right? And you never typo, right?

I doubt he does, but i also doubt that installing a framework via maven brings in 1,000 implicit dependencies from 1,000 untrusted authors, unlike in JS land. Edit: react, webpack, babel, babel-preset-env bring in 1,257 dependencies. Try vetting all those by hand.

I think my (primarily Java) project at work brings in about 50-100 external dependencies. That includes some ridiculously large frameworks, like Spring. Honestly, I don't know because I don't have dependency problems.

You know how hard it would be for me to vet the dependency if I did have a dependency problem? "mvn dependency:tree > deps.txt." It would take half the day, but I could vet them all.

I also have a Django project on the side. It has 8 dependencies. I have vetted all of them very carefully. It's smaller than the work project, but that's not the reason why it has fewer dependencies than a typical JS mess. It has fewer dependencies, because Pythonistas have a philosophy and cultural practices that produces quality software with lots of functionality included.

Post reply on HN