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

71–80 of 133 posts

Re: Strong_password Rubygem hijacked

#71

Post by viraptor »

saurik wrote: post #65
zbentley wrote: post #34

Earlier quoted context omitted.

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.

We don't know that. Their system could've been compromised in some other way and the password captured.

Re: Strong_password Rubygem hijacked

#72

Post by viraptor »

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

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

That's solved in similar frameworks by separating open and read/write. You open (or inherit from somewhere) a logging socket, drop the open privileges, retain the permission to write to the log socket.

Re: Strong_password Rubygem hijacked

#73

Post by senorprogrammer »

fasterdom wrote: post #35
pharrington wrote: post #32

Earlier quoted context omitted.

> This is a gem that checks the strength of a user-submitted password Does it, though? https://github.com/bdmac/strong_password/blob/master/lib/str...

Indeed, replacing this with the list of top 100 passwords would be much more effective.

A long time ago I made a gem that does pretty much this: https://github.com/senorprogrammer/pil

If you want this functionality, I recommend not using it as-is, given the security vuln GitHub is currently reporting. Rather, anyone has my permission to copy the code verbatim into your project. It's a pretty simple gem.

Re: Strong_password Rubygem hijacked

#74

Post by rgovostes »

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 design of macOS and iOS has been moving this way. Many of Apple's first-party applications and frameworks have been broken down into backend "XPC services" that (attempt to) follow the principle of least privilege[1]. Each service runs in a separate process, the system enforcing memory isolation and limiting access to resources (sandboxing).

It's a good idea on paper, but has caveats. Every service is responsible for properly authenticating its clients, and needs to be designed so that a compromised client cannot leverage its access to a service to elevate privileges. Sandboxes are difficult to retrofit onto existing programs. The earlier, lowest-common-denominator system frameworks were not originally written with sandboxing in mind. There are numerous performance drawbacks.

For Apple ecosystem developers, XPC services are also how "extensions" for VPN, Safari ad blockers, etc. are written, for a mix of security and stability benefits.

Though funnily enough, as Apple has pursued these technologies, many HN commenters have decried the walls of the garden closing in.

1: https://en.wikipedia.org/wiki/Principle_of_least_privilege

Re: Strong_password Rubygem hijacked

#75

Post by russelldavis »

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.

This idea is baked into the core of Deno. See, for example, https://deno.land/manual.html#permissionswhitelist.

Re: Strong_password Rubygem hijacked

#77

Post by dwohnitmok »

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.

Safe Haskell, a GHC extension, is one example in this space. https://downloads.haskell.org/~ghc/latest/docs/html/users_gu...

Its biggest selling point is that a lot of capability safety could be inferred in packages without the package author separately specifying capabilities.

The basic idea is to disallow the remaining impure escape hatches in Haskell in most code, requiring library authors of libraries that do require those escape hatches (e.g. wrappers around C libraries) to assert that their library is trustworthy, and requiring users to accept that trustworthy declaration in a per-user database.

It actually was very promising because the general coding conventions within Haskell libraries made most of them automatically safe, so the set of packages you needed to manually verify wasn't insane (but still unfortunately not a trivial burden, especially if your packages relied on a lot of C FFI).

Unfortunately I have yet to see it used in any commercial projects and it seems in general not to get as much attention as some other GHC extensions.

Re: Strong_password Rubygem hijacked

#78

Post by your-nanny »

javagram wrote: post #7
frizkie wrote: post #2

It seems to me like the only way to really provide any sense of security is to force gems uploaded to RubyGems to be signed. There is some discussion here ( https://github.com/rubygems/guides/pull/70 ) about why the Rubygems PGP CA isn't really worth using in its current state. As we've seen with Javascript dependencies, we can only put off dealing with this problem for so long.

Another solution would be changing the ecosystem to no longer be reliant on so many third party dependencies. For instance if I am using Java and I build my web app with only Spring Framework, I can have a lot more confidence that one of my JARs hasn’t been backdoored than I can in an ecosystem where it’s regularly the practice to pull 100s of dependencies from different individual FOSS developers, where it’s difficu…

I know there has been some recent discussion within the python community that Python's batteries included philosophy is failing the community, with some arguing that the python standard library should be streamlined. But I see third party dependencies as often a liability both for security and a kind of technical debt (I maintain infrequently used but essential legacy python applications)

Re: Strong_password Rubygem hijacked

#79

Post by dmix »

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…

A whole lot of security is playing whack-a-mole at the end of the day.

Re: Strong_password Rubygem hijacked

#80

Post by rattray »

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

Yes. I think that we need to see a full security report from rubygems.org on this. This could be bigger than just the one package.

Agreed – a postmortem from rubygems.org on how the takeover occurred, and would be prevented next time, is something the Ruby community should expect/demand.
Post reply on HN