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

121–130 of 237 posts

Re: Malicious crossenv package on npm

#121

Post by Spivak »

hitgeek wrote: post #98

this is really bad for npm. I think they hold some responsibility in allowing an obviously malicious package to impersonate popular packages. I would like to see an official response with action plan. I recall this attack vector being discussed in the aftermath of left-pad. an unfortunate irony is that the current post on the npm blog is "Securing the npm registry" from 12hrs ago.

Not really much they can do other than take it down and maybe 'protect' some popular packages from typo squatting by reserving some common misspellings. They're a public repository where users upload arbitrary code. The trust relationship really isn't there.

You trust NPM to be secure and serve exactly the code that the author published unmodified.

You trust the author to not act maliciously. Nothing you can really do if a user voluntaitally installs leet-virus.

Re: Malicious crossenv package on npm

#122

Post by vacri »

pfooti wrote: post #71
danjoc wrote: post #60

Earlier quoted context omitted.

>nobody but the most tinfoily of us is going to do that Are you characterizing people who verify keys as crazy? It's not like you can't just reach out to @kentcdodds and get an answer in under 5 hours as Oscar Blomsten just did in the OP.

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

Re: Malicious crossenv package on npm

#123

Post by thehardsphere »

pfooti wrote: post #107
jjnoakes wrote: post #30

Earlier quoted context omitted.

I wish the node ecosystem would learn from more mature ones. I would like to see a curated set of popular libraries that are stabilized and blessed, and a core group that handles security updates and upgrading packages in the blessed set.

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.

Re: Malicious crossenv package on npm

#124

Post by thehardsphere »

doingmyting wrote: post #14
colejohnson66 wrote: post #12

Earlier quoted context omitted.

The `left-pad` debacle a year ago[0] should've served as a wake up call to people writing projects with hundreds of dependencies. [0]: http://left-pad.io

It's next to impossible for the average team to avoid hundreds of dependencies as their project grows though. You could write your own everything, but then what's the benefit of the node ecosystem? Edit: spelling

Maybe the benefit of the node ecosystem isn't as great as you imagine if a project requires hundreds of dependencies when projects that are part of other ecosystems only require dozens.

Re: Malicious crossenv package on npm

#125

Post by KirinDave »

jsjohnst wrote: post #109
KirinDave wrote: post #100

Earlier quoted context omitted.

Which part of the statement implied "vilgilate justice." The part with the law enforcement or the "social reputation" part that is exactly the words game theory uses when discussing bad actor in a problem. Just so I can modify my words to avoid future misunderstanding.

> dox the perpetrator to kingdom come I can't believe it wasn't obvious, but that's the part which implies vigilante justice. From Wikipedia[0]: A vigilante is a civilian or organization acting in a law enforcement capacity (or in the pursuit of self-perceived justice) without legal authority. Doxing has a very specific meaning and it directly implies taking matters into your own hands, aka vigilante. [0] https://en.…

Doxxing means sharing people's relevant personal details that you gained without the targets consent.

In the case of malicious scammers, doxxing them so they can be cut off from other code repositories seems less like "vigilante justice" and more like "a public responsibility."

Re: Malicious crossenv package on npm

#126

Post by jhundal »

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

I'm guessing maven feels safer because its packages must be compiled against a specific interface and few if any execute any code during setup. Maven is rarely if ever used to install interactive tools like npm very often is. Maven is not a reasonable analog here.

Somewhat agreed, maven is a build tool and packages it downloads do not execute code through maven. This does not preclude malicious typosquatting packages making it into applications built using it, but does provide some option for reducing the attack surface.

In practice I think most developers would be running their project on the same exact box as they use for building it, which nullifies the separation of build/runtime environment. The reason that we don't typically see egregious typosquatting in the Java ecosystem is that Sonatype has a manual check on the claimed namespace for the organization publishing a project (among other checks). npm, Inc. could do this, but they so far have chosen not to.

Edit: Typos/clarity

Re: Malicious crossenv package on npm

#127

Post by KirinDave »

nullstyle wrote: post #113
KirinDave wrote: post #91

Earlier quoted context omitted.

I think you're reading a lot more into my comment than I wrote. It's not "vigilante justice" to ban known scammers and circulate blacklists of them. It's how our community functions.

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 an expectation of privacy as they attack other people, violating similar rights.

Re: Malicious crossenv package on npm

#128

Post by KirinDave »

vacri wrote: post #116
KirinDave wrote: post #42

Earlier quoted context omitted.

> I really like how the NPM simultaneously insults two legends in crypto and does _nothing_ to protect the node ecosystem, deferring to "better solutions" that don't exist and will never exist. But they're right. What exactly would PKI do here? Someone is generating confusion. You could argue that maybe a PKI solution could be used to inform the UI such that users are less likely to make mistakes, but browbeating NPM…

> everyone has this problem. No, they don't. Some people actually implemented the "web of trust (sigh)". Security is hard; the answer is not to just go "too hard, kick the can down the road" and then make excuses when the time comes for damage control. NPM being an order of magnitude larger means that more focus should be given to security, not less, since it has that extra noise acting as another way to hide malicio…

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

Re: Malicious crossenv package on npm

#129

Post by Veedrac »

All of this seems fixable by just providing decent UI protections. Error when typo-squat domains near-alias more popular packages; force them to pass a flag to override.

Is there a reason this isn't done, or has it just not been allocated the time to build it?

Re: Malicious crossenv package on npm

#130

Post by hedora »

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…

I guess you are aguing that you can't find 10-ish core npm maintainers that can be bothered to sign keys for well-known developers and bootstrap a web of trust that would then provide crypto attestation and perform basic gatekeeping on new package submissions.

It's not like you'd have to write a bunch of software. Also, other mission-critical open source repos have been doing this for at least a decade, so you don't even have to invent and validate a new set of processes for this.

For me, this calls into question the reliability and quality of the whole npm infrastructure and the packages it hosts.

Also, blaming users because npm (knowingly, through willful negligence) hosts malicious packages that typo squat on legitimate packages doesn't seem appropriate to me.

Post reply on HN