Live data from Hacker News

Malicious crossenv package on npm

twitter.com

131–140 of 237 posts

Re: Malicious crossenv package on npm

#131
post #107

Earlier quoted context omitted.

who gets paid to support that ecosystem, and who does the paying? as a simple example, I use the hapi.js server framework (because it is awesome). At one point, it was supported by Walmart Labs. It isn't anymore - it's mostly supported by the original author (Eran Hammer), who is getting paid less than $5k per month to develop / support it via patreon (and take a look at the bimodal distribution on his patreon page).…

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

Re: Malicious crossenv package on npm

#132
post #105

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.

Yes

https://github.com/s4u/pgpverify-maven-plugin

There's also this,

https://jeremylong.github.io/DependencyCheck/dependency-chec...

Because you want to know when a dependency has a vulnerability, even when the developers are legit.

Re: Malicious crossenv package on npm

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

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 pattern for what package space you're allowed to use based on website or company ownership.

The system is highly automated but you have to wait to get your namespace approved. And it's not unrealistic to do this with npm, maven has somewhere over a million packages.

Re: Malicious crossenv package on npm

#134
post #107

Earlier quoted context omitted.

who gets paid to support that ecosystem, and who does the paying? as a simple example, I use the hapi.js server framework (because it is awesome). At one point, it was supported by Walmart Labs. It isn't anymore - it's mostly supported by the original author (Eran Hammer), who is getting paid less than $5k per month to develop / support it via patreon (and take a look at the bimodal distribution on his patreon page).…

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.

Name one.

Re: Malicious crossenv package on npm

#135

Earlier quoted context omitted.

Or package authors should start using scoped packages. Instead of publishing as cross-env you publish as @guy/cross-env That makes typosquatting harder, and can help give users some ideas of packages which are by the same authors. NPM could help by allowing packages to be published both to the "global namespace" AND as a scoped package automatically. (In other words, always allow accessing any global package by it's…

You could still typosquat as e.g. @guyy/cross-env.

You would have to maintain that all package names are unique. The "cross-env" part would have to still be unique.

Re: Malicious crossenv package on npm

#136

Earlier quoted context omitted.

I can't reply directly, but in another subtree you asked: > Which part of the statement implied "vilgilate justice." To put my own 2 cents in: Doxxing someone is generally considered an attack, at least in some internet circles. It's pretty vigilante if you ask me, especially when we've seen some pretty striking examples of doxxing gone wrong in the past.

If you connect to my resources and use my systems to hurt other people, you don't really have an ethical leg to stand on if I share what details about you I have with law enforcement and other service providers. It's absolutely an attack, but it's an "attack" of a kind that is acting to end misuse and widespread tampering. It's difficult to imagine a coherent ethical system that gives the author of malicious software…

Doxxing in my experience implies publishing their info publicly. That's certainly what I thought you were saying.

I'm fine sharing with law enforcement, but sharing with other service providers seems to be a slippery slope. I imagine a dev losing access to their github account because they used a shitty password on their npm account and got compromised. That would suck.

I'd much rather we invent a better UI for dealing with software dependencies, but alas.

Re: Malicious crossenv package on npm

#137
post #122
post #71

Earlier quoted context omitted.

I'm working on a node-based REST endpoint. It's nothing special - it looks up stuff in the database, does CRUD things, pokes postgres, has a cache layer in redis, a websocket for handling sidechannel stuff like model update events for realtime data updates and so on. It has 514 dependencies in total. It's actually only 39 real dependencies, the rest are subs and sub-subs (after removing duplicates). Also, some of tho…

> only tinfoil-crazies will verify that stuff vs > my simple webapp has 514 de-duped dependencies We have different ideas of 'crazy'.

i've been building web-based software since 1998, when I had to manually parse http requests on stdin (and read headers from env variables) in a C application running as a cgi-bin plugin, remembering to end the stream with two \n characters. i (a) know what i am doing and (b) am super-glad i don't have to parse a lot of jank to get to the interesting parts of the code.

every approach has weaknesses. I'm pretty sure there's tradeoffs everywhere: ergonomics vs speed, security vs inclusivity, etc. I'm also pretty sure it's uncool to make implications about my mental health in public.

Re: Malicious crossenv package on npm

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

Signed packages tell you one and only one thing: that the package was signed by a particular key.

They don't tell you that the package was signed by someone you think should be authorized to produce that package.

Linux distros can get away with signing everything because there's typically a very small set of people the distro's organizational structure trusts to make packages, and thus a very small set of keys and real-world identities to verify.

Open-to-the-public package systems cannot hope to verify the identity of every person who creates a package, and thus cannot provide you with the web-of-trust model you want (since what you seem to want is not "is this signed by a PGP key" but rather "is this signed by a PGP key I personally think should be authorized to make packages").

Re: Malicious crossenv package on npm

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

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.

Re: Malicious crossenv package on npm

#140

This attack has been previously described in the paper "Typosquatting package managers": Paper: http://incolumitas.com/data/thesis.pdf Blog post: http://incolumitas.com/2016/06/08/typosquatting-package-mana... Discussion: https://news.ycombinator.com/item?id=11862217 https://www.reddit.com/r/netsec/comments/4n4w2h/ The paper also discusses possible mitigation measures, including prohibiting registering new packages w…

Typosquatting can be prevented by premoderation in the repository.
Post reply on HN