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

Strong_password Rubygem hijacked

withatwist.dev

Post reply on HN
Print view View original

61–70 of 133 posts

Re: Strong_password Rubygem hijacked

#61

Post by sigotirandolas »

fasterdom wrote: post #9

We need a sort of capability and permission method for libraries. For example a "strong_password" library should only by given "CPU compute" permissions, no I/O. But even with this, the problem will be like we see on phone, popular libraries will require all the permissions. You'll want to install React, and React + it's 100 dependencies will request everything.

The skeptic in me thinks that it's never going to work in practice due to 'worse is better': Any system with the 'I/O vs no-I/O' system will have more friction than one without it, and there is no measurable benefit until you get hacked, so most people will not use it (or declare everything as I/O).

Re: Strong_password Rubygem hijacked

#63

Post by acdha »

nordsieck wrote: post #29
kibwen wrote: post #24

Earlier quoted context omitted.

To be honest, even the coarsest-possible permissions of "can do I/O" vs. "can't do I/O" would be exceedingly effective at stymieing these sorts of attacks; all malicious software of this sort needs to do I/O at some point, and relatively few libraries actually have a good excuse to do I/O (though logging might be thorny). That said it seems easier said than done to impose those sorts of restrictions on a per-dependen…

> That said it seems easier said than done to impose those sorts of restrictions on a per-dependency basis. Isn't this the sort of thing type inference is made for? Along with return types, functions have an io type if they're marked (std lib) or if they contain a marked function. Otherwise they have the pure type.

Doing this usefully does require more than just “does IO” — e.g. does that mean it can load another module, read a list of too-common passwords, write to a log file, or read your ~/.aws/credentials? Similarly, does allowing networking mean it can talk to anything or just a few well-known hostnames and ports?

This isn’t to say that it’s a bad idea but there are a ton of details which get annoying fast. I know the Rust community was looking into the options after the last NPM hijack was in the news but it sounded like it’d take years to make it meaningfully better.

Re: Strong_password Rubygem hijacked

#64

Post by redsymbol »

kibwen wrote: post #24
fasterdom wrote: post #9

We need a sort of capability and permission method for libraries. For example a "strong_password" library should only by given "CPU compute" permissions, no I/O. But even with this, the problem will be like we see on phone, popular libraries will require all the permissions. You'll want to install React, and React + it's 100 dependencies will request everything.

To be honest, even the coarsest-possible permissions of "can do I/O" vs. "can't do I/O" would be exceedingly effective at stymieing these sorts of attacks; all malicious software of this sort needs to do I/O at some point, and relatively few libraries actually have a good excuse to do I/O (though logging might be thorny). That said it seems easier said than done to impose those sorts of restrictions on a per-dependen…

> few libraries actually have a good excuse to do I/O (though logging might be thorny).

Yeah, logging would be tricky...

Maybe a "logging" capability could be created. Separated from other I/O.

Such a capability would be weird, and nonstandard, and messy, cutting across several several abstraction layers. But if pulled off, it might be worth the effort.

Re: Strong_password Rubygem hijacked

#65

Post by saurik »

zbentley wrote: post #34
MrStonedOne wrote: post #6

The unanswered question is still how this `kickball` account gained control of the gem. > The gem seems to have been pulled out from under me… When I login to rubygems.org I don’t seem to have ownership now. Bogus 0.0.7 release was created 6/25/2019. The way I see it, there are a few options: 1. The rubygem was transferred by ruby staff to this account. 2. The maintainer's account was hijacked and then it was transfe…

Option 2 is overwhelmingly likely, IMO. Phishing, password reuse, credential scraping/spamming, and plain old brute force are unbelievably common. That said, the other two options bear investigation too. Just don't spend time looking for a cold breeze from an un-caulked window frame when the screen door is open.

The true irony, of course, is that the package in question is designed (whether it does or not isn't the point, though I guess if it isn't very good then this becomes all the more humorous) to help prevent people from reusing common passwords or choosing passwords that are easy to brute force ;P... clearly the author should have used this package to select their password that protected the uploads of this package.

Re: Strong_password Rubygem hijacked

#67

Post by acdha »

nneonneo wrote: post #13
matthewmacleod wrote: post #11

Earlier quoted context omitted.

I doubt that any solutions which start off as “let’s change the whole universe” are going to get very far. Yes, the situation sucks. I just looked at the frontend of a relatively small app we use for administration, and it depends on almost 5000 node modules versions. But this problem needs to be dealt with as soon as possible, and I don’t think that a fundamental change in development culture—making everything harde…

5000? Wow. That's gotta be a pretty sizable fraction of the entire Node library ecosystem. Does it count duplicates? With a dependency forest that large, it's small wonder that not more JS projects aren't compromised by bad dependencies...

Create React App is pretty popular and it has 36k dependencies. That’s not saying everyone using it ships every one of those but that’s definitely a LOT of people who could potentially introduce malware, often with a fair chance of it being deniable.

Re: Strong_password Rubygem hijacked

#68

Post by acdha »

Papirola wrote: post #66

why not just restrict the production environment to not open ports other than 80 and not to create TCP channels to unauthorized hosts?

It’s effective but tends to be a considerable amount of work to maintain, especially since the web is more dynamic these days: imagine what it would take to filter only authorized connections to a service hosted on AWS, for example, where anyone in the world can get IPs in the possible range and even put data on white-listed hostnames like S3. You’re basically building an allow list of host names, intermediating every update path, etc. and dealing with things which were designed with a more open model — e.g. do you disable things like OCSP or whitelist more third-party resources?

This also heavily encourages microservices since most non-trivial applications will have some reason to connect to fairly arbitrary resources. Hopefully that can be sandboxed well but relatively few apps were designed that way and that general class of missing things which weren’t supposed to work is notoriously easy for even experienced teams to miss.

Re: Strong_password Rubygem hijacked

#69

Post by hirundo »

> I went line by line linking to each library’s changeset. This due diligence never reported significant surprises to me, until this time.

Mad props to the author, Tute Costa, for doing this. It's a large investment of time for usually no return, so I think very few people do. And his (?) reaction to finding this was quite effective.

Thank you for your service sir.

Re: Strong_password Rubygem hijacked

#70

Post by crabl »

fasterdom wrote: post #9

We need a sort of capability and permission method for libraries. For example a "strong_password" library should only by given "CPU compute" permissions, no I/O. But even with this, the problem will be like we see on phone, popular libraries will require all the permissions. You'll want to install React, and React + it's 100 dependencies will request everything.

Couldn't you theoretically shove all of your untrusted "non-I/O" libraries into a Service Worker? They wouldn't have direct access to the DOM or network I/O that way. It would involve writing some glue code, but perhaps it's worth trading that off for increased "security" (trust)?

EDIT: never mind, looks like I was mistaken about the network i/o part of this... Might be interesting to have a browser-level "sandboxed service worker" for this purpose though...

Post reply on HN