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

Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

bleepingcomputer.com

Post reply on HN
Print view View original

741–750 of 1001 posts

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#741

Post by zelos »

ratorx wrote: post #221
pc86 wrote: post #179

Earlier quoted context omitted.

Are these really RCE vulnerabilities? Looking at it systematically I only see this as an RCE vector if you're doing one or more things very wrong. This assumes that packages are immutable and an author can't update a version that's already there. This is how NuGet works, and IMO is how any remotely sane package manager will work. There's no reason for a version to be mutable in this context. Pegging to a specific ver…

The tool should take some blame here. I agree that it’s ultimately the developers fault for allowing code to be automatically injected from not fully trusted sources on minor updates, but the package manager makes it way too easy to do. For example, when I npm install a package, it defaults to specifying a semver compatible version in package.json, rather than doing the secure thing and pinning a version. But whether…

> Pinning versions means that you will keep using an insecure version of a dependency until you update

Which is why you schedule time each sprint/release to check your dependencies and upgrade them in a controlled fashion.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#742

Post by throwaway47292 »

create-react-app has thousands of transient dependencies, being worked on by maybe 40000 developers (possibly more), 1 in 100 people is a sociopath, and 1 in 100 is a psychopath, and looking at the general population around 1 in 100 is a criminal. There is selection bias in the open source community, but still, we can assume when you do `create-react-app` you are going to run the code of ~50 people that don't have your best intentions at heart.

Supply chain attacks are one of the best attack vectors.

So vet your dependencies and assume them malicious.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#743

Post by asddubs »

0x0nyandesu wrote: post #734
lrvick wrote: post #722

Earlier quoted context omitted.

Security auditor here. Every time I see a client importing unsigned code with no evidence anyone they trust has reviewed it, I flag it as a supply chain attack vector in their audit and recommend mitigations. Some roll their eyes, but I will continue to defend it is a serious issue almost every company has, particularly since I have exploited this multiple times to prove a point by buying a lapsed domain name that mi…

You can say the same thing about the entire Linux stack

any operating system, really, if you want to play that game

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#744

Post by raesene9 »

sailingparrot wrote: post #262
raesene9 wrote: post #7

Earlier quoted context omitted.

That seems like a bit of a shaky ground to stand on for GH. If someone publishes code for themselves, and at no time asks anyone to take it as a dependency, then at a later date they change that code in a way that breaks other people's use of it, do GH then take over the account?

Sure, trying to find exactly where the malicious line gets crossed is pretty hard and subjective, and maybe that will bite GH one day. But this specific case is not anywhere near that line, the sole intent of those commits was to break others, and he admitted so himself. This is like arguing about whether the james webb telescope really is in space since we don't have a precise consensus about what altitude is consid…

I'm sure this case is clear, my point was around the wider principal that by going down this line GH set themselves up as arbiter of "malice"

To take a trickier example, say a GH user has a lib, then decides to re-architect it, breaks the API and for their own purposes pushes it to an existing version, breaking all other use of it. Now that's a nasty thing to do, but is it malice?

Another, real-world, example is I know of a user who publishes "honey PoCs" for security issues, where the repo. appears to be a exploit code but actually isn't. He's been accused of malice in doing this, but his intent is research for a talk on how people use code blindly without testing.

Is that malice, should GH take his account down?

By stepping into this area GH are going to have to find answers to this and also the problem of who maintains the repos of accounts they nuke?

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#745

Post by asddubs »

hn_throwaway_99 wrote: post #392
bastardoperator wrote: post #108

Should I get paid for my multiple contributions to faker (I don't think I should)? I've submitted several PR's for generating data all of which were accepted. Even back then the maintainer was barking about money... Honestly the project would be better off forked. He did not write this library entirely by himself, at this point I just see him as holding other committers contributions as hostage. It's a bad look, why…

> It's a bad look, why would anyone want to deal with him after this stunt is beyond me. The maintainer appears to be unwell: https://abc7ny.com/suspicious-package-queens-astoria-fire/64...

is this actually the same guy or some other person named marak who happens to be a software dev? The article appears to be from september 2020

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#746

Post by cercatrova »

glenneroo wrote: post #668
fault1 wrote: post #645

Earlier quoted context omitted.

seems like he has a history of this (HN 2010): https://news.ycombinator.com/item?id=1448309

and he seems quite proud of getting banned from Github in 2013: https://youtu.be/varf6oWaFtU?t=202

Well, he just got banned again from GitHub today.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#747

Post by can16358p »

jeffparsons wrote: post #535
can16358p wrote: post #475

Earlier quoted context omitted.

Moreover, anyone who either has malice intentions (or depend on other packages, of whom authors do) can make the whole process much less noticeable with relying on variables from URLs that get executed, which may themselves be linked to other dynamic dependencies, creating all sorts of logic/time bomb or RCE attacks. That kind of behavior would be practically impossible to code-review for lots of packages that rely o…

This is what the folks working on WASM/WASI and related projects are trying to achieve. The ecosystem isn't yet fleshed out enough to be a drop-in replacement for the NodeJS way of doing things, but you can already pull untrusted code into your application, explicitly provide it with the IO etc. capabilities it needs to get its job done (which is usually nothing for small packages, so not much bureaucracy required in…

I think this will be the way of going. It resembles me of having all server components all over the place creating a mess, and now we have Docker and Kubernetes. From what I see this would be a more lightweight version of containerization: not for VMs/services but for each JS package.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#748

Post by asddubs »

evouga wrote: post #556
sillysaurusx wrote: post #195

Earlier quoted context omitted.

This is scary, and I don’t know why people here aren’t losing their minds. I think someone should make a big deal about this. What would be the first step? On the other hand, my GitHub was once suspended (and all repos shuttered) for posting gists that looked like spam to some algorithm. It was extremely unsettling, and they need to do a better job communicating. But they may have suspended the account because they t…

For a long time I've owned a premium GitHub account and would roll my eyes at colleagues who insisted on using GitLab, as I felt that GitHub had a clearly superior user experience. I have to say, though, that every time in recent memory that GitHub has popped up in the news, it's for something that's made me sigh. The only thing still keeping me one of their customers is the painfulness of transferring over all of my…

gitea seems pretty nice, but you have to host it yourself

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#749

Post by mid-kid »

0x0nyandesu wrote: post #734
lrvick wrote: post #722

Earlier quoted context omitted.

Security auditor here. Every time I see a client importing unsigned code with no evidence anyone they trust has reviewed it, I flag it as a supply chain attack vector in their audit and recommend mitigations. Some roll their eyes, but I will continue to defend it is a serious issue almost every company has, particularly since I have exploited this multiple times to prove a point by buying a lapsed domain name that mi…

You can say the same thing about the entire Linux stack

Not really, individual package developers don't have as much inmediate control over the repository's state as they do with NPM. Packages go through a review by one of the trusted developers and sometimes automated QA and testing (including as of late reproducibility testing, i.e. does the source match the binary?), before being uploaded to the repository.

If you can't trust the team behind the distro, then sure, your supply chain is compromised, but it's significantly less likely for a single package developer to cause any damage, as all the big distros have rather extensive policy and procedures to prevent such things.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#750

Post by jopsen »

lrvick wrote: post #722
notRobot wrote: post #21

Here's my $.02: Packages are literally remote code exec vulns in the hands of package authors. At the very least, it takes them under a minute to break your app, simply by deleting their package. Read the article. This is not the first time it's happened, and it's not going to be the last. [0] I write backends (mostly in PHP, although not exclusively), and I release a lot of my code under libre licenses. But I don't…

Security auditor here. Every time I see a client importing unsigned code with no evidence anyone they trust has reviewed it, I flag it as a supply chain attack vector in their audit and recommend mitigations. Some roll their eyes, but I will continue to defend it is a serious issue almost every company has, particularly since I have exploited this multiple times to prove a point by buying a lapsed domain name that mi…

If we are willing to admit that repositories like npm are useful, what can be done to mitigate these issues?

Is there some tooling we can build?

Post reply on HN