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

221–230 of 237 posts

Re: Malicious crossenv package on npm

#221

Post by krapp »

lsiebert wrote: post #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…

Is there likely to be a good reason for one package name to be two or three character transforms away from another?

Maybe have all packages be scoped under a namespace, and then globally require a minimal uniqueness for the package name itself.

Re: Malicious crossenv package on npm

#222

Post by krapp »

ris wrote: post #160
stu_k wrote: post #40

Earlier quoted context omitted.

I'm confused, how would the above help with a typosquatting package? The issue here is that `crossenv` is malicious, and `cross-env` isn't. The signatures would all be ok in both cases.

It wouldn't. Nothing will help with package managers that follow the "wild west" or "any old crap" model where there is no maintainer or distributor between the developer and consumer that is allowed to perform any sort of quality control or sanitisation. This is what makes me hugely favour the "maintained" model followed by distributions or nix/guix. The wild west model scares the bejesus out of me to be honest.

The "wild west" model doesn't disallow anyone from providing quality control, it just doesn't enforce one particular person or entity's idea of what quality control should be.

Re: Malicious crossenv package on npm

#223

Post by KirinDave »

graphememes wrote: post #216
KirinDave wrote: post #206

Earlier quoted context omitted.

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.

I didn't reply to lmm. I asked that question of danjoc.

Is that not obvious from scrolling?

Re: Malicious crossenv package on npm

#224

Post by KirinDave »

sloppycee wrote: post #214
KirinDave wrote: post #211

Earlier quoted context omitted.

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

Distributed trust isn't better than centralized trust. In fact, it'll fail more often. It's just that the failures have varying degrees of severity.

Same principle as saying, "I will make my website more reliable by adding more servers." In fact you make it less reliable by doing so, you just change the severity of the problems.

And we've seen economic mechanisms compromise signed star-shaped trust graphs. E.g., all these atom plugins with features/spyware circulating because a small handful of companies think it's a business model. That's literally just buying the property from folks and ruining it. That's a very powerful attack against a web of trust and often cheaper than the fake cert attack, which is actually something you can guard against if you feel inclined to do so.

Re: Malicious crossenv package on npm

#225

Post by raggi »

thehardsphere wrote: post #219
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?

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

2. If you don't whitelist your deps, then your dep chain can change with any update. Signing keys prove only that the publisher held the keys, not that they aren't malicious, or that the keys aren't stolen.

3. Fat fingering your pom is no different, this argument is as wasteful as 0 and 1 and you know it.

Re: Malicious crossenv package on npm

#226

Post by raggi »

thehardsphere wrote: post #220
orf wrote: post #217

Earlier quoted context omitted.

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

Npm being split means more metadata, not necessarily more code. You admit to not reading your code or inspecting your dep, and you assert that you have no problems - based on what?

Your deps.txt is barely different than a lock file here.

Reading the code from dependencies is not really hard anywhere here.

Re: Malicious crossenv package on npm

#227

Post by raggi »

raggi wrote: post #225
thehardsphere wrote: post #219

Earlier quoted context omitted.

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

2. If you don't whitelist your deps, then your dep chain can change with any update. Signing keys prove only that the publisher held the keys, not that they aren't malicious, or that the keys aren't stolen. 3. Fat fingering your pom is no different, this argument is as wasteful as 0 and 1 and you know it.

And while we're at it

https://issues.apache.org/jira/plugins/servlet/mobile#issue/...

Also, if you read the docs you'll notice that the deploy plugins encourage users to put their central passwords in an xml file in the plain AND their pgp key passphrase in another, in the plain. No joke. Read the docs.

Re: Malicious crossenv package on npm

#228

Post by thehardsphere »

raggi wrote: post #225
thehardsphere wrote: post #219

Earlier quoted context omitted.

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

2. If you don't whitelist your deps, then your dep chain can change with any update. Signing keys prove only that the publisher held the keys, not that they aren't malicious, or that the keys aren't stolen. 3. Fat fingering your pom is no different, this argument is as wasteful as 0 and 1 and you know it.

I didn't say that "I don't whitelist my deps." I said I don't need to manually verify every tiny thing that I whitelist.

If you actually knew what you what you were talking about, you would know that you can't specify a dependency in a Maven POM without specifying a version, so everything is effectively version pinned and doesn't magically change unless you do it explictly. And you can't change an artifact after it has been released; you have to issue a new release with different coordinates. These are features of Maven that npm is missing that would make it vastly more secure than it is now.

And fat fingering a pom is different, because it requires many more mistakes to download some other software package than the one intended. That's what this discussion is about right? That it's absurdly easy to download the wrong package on npm but not other package managers, because npm is an insecure package manager.

Re: Malicious crossenv package on npm

#229

Post by thehardsphere »

raggi wrote: post #227
raggi wrote: post #225

Earlier quoted context omitted.

2. If you don't whitelist your deps, then your dep chain can change with any update. Signing keys prove only that the publisher held the keys, not that they aren't malicious, or that the keys aren't stolen. 3. Fat fingering your pom is no different, this argument is as wasteful as 0 and 1 and you know it.

And while we're at it https://issues.apache.org/jira/plugins/servlet/mobile#issue/... Also, if you read the docs you'll notice that the deploy plugins encourage users to put their central passwords in an xml file in the plain AND their pgp key passphrase in another, in the plain. No joke. Read the docs.

An injection attack on a download is not one of the problems we're actually talking about here. That's a problem that affects any package manager.

And it's patently false to say that the deploy plugin documentation encourages you to include that information. They very clearly preface that with "if your repository is secured" and use the explicit example of an internal repository within a corporate context. People smart enough to read that documentation in detail should also be smart enough to determine when it is and isn't a good idea to do that.

Re: Malicious crossenv package on npm

#230

Post by thehardsphere »

raggi wrote: post #226
thehardsphere wrote: post #220

Earlier quoted context omitted.

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

Npm being split means more metadata, not necessarily more code. You admit to not reading your code or inspecting your dep, and you assert that you have no problems - based on what? Your deps.txt is barely different than a lock file here. Reading the code from dependencies is not really hard anywhere here.

> you assert that you have no problems - based on what?

The software works as intended and I know that my dependencies have not changed without me explictly changing them.

> Your deps.txt is barely different than a lock file here.

That command produces a tree of all dependencies and their dependencies. I don't know what that has to do with a lock file.

Post reply on HN