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

31–40 of 133 posts

Re: Strong_password Rubygem hijacked

#31

Post by djur »

nneonneo wrote: post #3

This is a gem that checks the strength of a user-submitted password. It has a large number of downloads (37,000 on the legitimate 0.0.6 version). It looks like it's made to be integrated on webservers. The modified gem downloaded and executed code stored in a editable Pastebin, meaning that the code could have changed at any time. Presumably, the malicious code would activate just by browsing any page on the affected…

Good analysis, but I'm not sure about "a large number of downloads". Download counts can be pretty inflated due to CI/deployment processes that reinstall gems from scratch repeatedly. I've seen open-sourced gems that never got any real usage outside their original company get that number of downloads.

To add a bit of a sense of scale here, the popular Devise gem that's used for authentication in many Rails apps has 52.7 million total downloads and almost 20k stars on GitHub. strong_password has 247k total downloads and 191 stars. It has three reverse dependencies, none of which I've ever heard of and none of which have any of their own reverse dependencies.

This suggests to me that this gem is used by less than 1% of Ruby web apps (probably substantially less) and, more importantly, if you have a dependency on this gem you probably know (because it'd be a direct dependency in your Gemfile, not a dependency of a dependency).

Re: Strong_password Rubygem hijacked

#32

Post by pharrington »

nneonneo wrote: post #3

This is a gem that checks the strength of a user-submitted password. It has a large number of downloads (37,000 on the legitimate 0.0.6 version). It looks like it's made to be integrated on webservers. The modified gem downloaded and executed code stored in a editable Pastebin, meaning that the code could have changed at any time. Presumably, the malicious code would activate just by browsing any page on the affected…

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

Re: Strong_password Rubygem hijacked

#33

Post by fasterdom »

mopierotti wrote: post #17
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.

I know this is about ruby, but it's worth noting that this kind of thing would be solved by effect systems, e.g. Haskell's IO type. If IO isn't part of the signature, you know it's cpu only. Furthermore, you can get more specific such as having a DB type to indicate some code only has access to databases rather than the internet as a whole.

While that might be true, you are not going to switch the world to program in Haskell.

We need a solution which also works for most used languages, JS/C++/Java/Python..., which suggests that it should be done at a higher level, maybe with OS involvement somehow.

Re: Strong_password Rubygem hijacked

#34

Post by zbentley »

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.

Re: Strong_password Rubygem hijacked

#35

Post by fasterdom »

pharrington wrote: post #32
nneonneo wrote: post #3

This is a gem that checks the strength of a user-submitted password. It has a large number of downloads (37,000 on the legitimate 0.0.6 version). It looks like it's made to be integrated on webservers. The modified gem downloaded and executed code stored in a editable Pastebin, meaning that the code could have changed at any time. Presumably, the malicious code would activate just by browsing any page on the affected…

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

Re: Strong_password Rubygem hijacked

#36

Post by bdcravens »

msbarnett wrote: post #21
bdcravens wrote: post #14

Earlier quoted context omitted.

Reinventing the wheel is one end of the spectrum, but so is putting a bunch of magic words in a file and thinking you needn't worry. (To be fair, too many tutorials hand wave away what really happens in Gemfile/package.json/etc and barely pay lip service, if at all, to the responsibilities that come with having those dependencies) I don't miss the "old" days of searching for libs, extracting a zip, and trying to figu…

> Reinventing the wheel is one end of the spectrum, but so is putting a bunch of magic words in a file and thinking you needn't worry. Yeah. I didn’t claim otherwise? Like I said, there are only trade-offs here. You can gain a ton of velocity if you abstract it all out to a file of 50,000 “magic words”; but obviously then your exposure to these issues is enormous. Trade-offs are like that. > I don't miss the "old" da…

> I think it’s mostly a completely false sense of security

I wasn't so much thinking about avoiding vulns due to added scrutiny as much as issues with updated libs, since most build processes pull gems, etc when deploying or rebuilding a container; I don't think many vendor the gems. Typically you'd ship the actual files you unzipped as opposed to letting the package manager grab the most recent version within version spec.

Re: Strong_password Rubygem hijacked

#37

Post by zbentley »

nneonneo wrote: post #25
adambyrtek wrote: post #19

Earlier quoted context omitted.

> With a rigid import system, each library would be forced to declare what it's going to import (including any system libraries), and then you could e.g. enforce a warning + confirmation any time an updated dependency changes its import list. Which means you would get warnings on pretty much any functional upgrade of most dependencies, which would make the whole system useless from a security point of view.

In theory, a point release of a library really shouldn’t be requiring new permissions, and you shouldn’t be randomly upgrading your code to newer major versions without checking for compatibility anyway. Why should a functional upgrade of a dependency introduce new dependencies anyway? A library that sets out to do a particular thing shouldn’t grow new features that require new capabilities willy-nilly.

> Why should a functional upgrade of a dependency introduce new dependencies anyway? A library that sets out to do a particular thing shouldn’t grow new features that require new capabilities willy-nilly.

Why not? I've often done upgrades with the sole purpose of replacing questionable, hand-written code with external dependencies I've discovered that do the same thing, but better (more features, more tests, more eyes on the code, more fixed issue reports than my often-closed-source code). From string parsing to networking, this happens a lot. The external contracts of my libraries don't change a bit, so why waste a major version? "I'm using someone else's code instead of what I YOLO'd myself" seems like a poor reason to rev a package version--and even if it's not, where do you draw the line? Cribbing code from StackOverflow?

Re: Strong_password Rubygem hijacked

#38

Post by msbarnett »

bdcravens wrote: post #36
msbarnett wrote: post #21

Earlier quoted context omitted.

> Reinventing the wheel is one end of the spectrum, but so is putting a bunch of magic words in a file and thinking you needn't worry. Yeah. I didn’t claim otherwise? Like I said, there are only trade-offs here. You can gain a ton of velocity if you abstract it all out to a file of 50,000 “magic words”; but obviously then your exposure to these issues is enormous. Trade-offs are like that. > I don't miss the "old" da…

> I think it’s mostly a completely false sense of security I wasn't so much thinking about avoiding vulns due to added scrutiny as much as issues with updated libs, since most build processes pull gems, etc when deploying or rebuilding a container; I don't think many vendor the gems. Typically you'd ship the actual files you unzipped as opposed to letting the package manager grab the most recent version within versio…

Typically your deployment process would pull gems based on hashes recorded in a lock file you committed, not pull arbitrary new versions automagically. So while I’m not shipping the actual file, something is verifying that I’m shipping files that have the hash I expect. Barring some very alarming developments in hash insecurity, it’s mostly a distinction without a difference.

Automating a “bundle update” to pull latest versions within spec and update the lockfile would be odd to my experience. You’d typically do that manually, (hopefully, if you’re competent) look at what changed, and retest (semver is great as long as everyone perfectly anticipates & categorizes every change’s impact. In the real world, however, ....) rather than blindly just letting a deployment run whatever.

Bad devs can do the stupidest thing imaginable in any system, though, so I don’t doubt this is out there.

Re: Strong_password Rubygem hijacked

#39

Post by nneonneo »

protomyth wrote: post #28
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.

So, we need a version of pledge from OpenBSD that can surround components / classes https://man.openbsd.org/pledge.2 https://www.youtube.com/watch?v=bXO6nelFt-E

Linux has seccomp for the same purpose. The most restrictive mode of seccomp permits only read, write and exit, which is good for a jailed CPU-only process (read/write commands from a pipe and exit when done - no opening new files or sockets).

Re: Strong_password Rubygem hijacked

#40

Post by zbentley »

derefr wrote: post #15
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.

If you look at dependencies as black-boxes that contain their own transitive dependencies, then sure, any given "root-level" dependency of sufficient complexity might end up requesting every permission. On the other hand, if each dependency in the deps tree had its own required permissions, and you had to grant those permissions to that specific dependency rather than to the rootmost branch of the deps tree that cont…

That seems like a strategy that would cause significant slowdowns and hassles in development.

High-level (i.e. consuming a lot of dependencies at a lot of levels) tools would simply apply a "allow everything" dependency policy rather than deal with tons of issue reports from people who wanted to import the high-level library in a less-than-root-permissioned project.

Additionally, lots of upgrades do increase the dependency surface. Resolving local usernames is a pretty fundamental thing a lot of dependencies would need. Now consider the libc switch from resolving names via /etc/passwd to resolving from multiple sources (including nslcd, a network/local-network service). If every dependency up the tree adopted a "lowest possible needed IO surface" permission model and then that change happened, it would be hell to pay: maintainers would take the shortest path and open up too many permissions; maintainers wouldn't upgrade and leave some packages trapped in a no-man's-land; or maintainers would give up on pulling in prone-to-changing-permissions dependencies, leading to even more fragmentation.

Post reply on HN