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

41–50 of 133 posts

Re: Strong_password Rubygem hijacked

#41

Post by zbentley »

msbarnett wrote: post #8
javagram wrote: post #7

Earlier quoted context omitted.

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…

Sure, obviously reinventing as many wheels as possible will minimize your exposure to third-party malfeasance. As in all forms of engineering there are, of course, no absolutes, only trade-offs to be made. The more wheels you reinvent, the slower your velocity for solving the core business problems that pay your bills. Moving too slowly can be fatal to the business. It’s a tricky balance. Signing isn’t perfect, but i…

> The more wheels you reinvent, the slower your velocity for solving the core business problems that pay your bills.

And the more mistakes you make, pissing off your users (or worse, compromising their data because you thought you could roll-your-own of some security critical dependency you ditched).

Re: Strong_password Rubygem hijacked

#42

Post by danShumway »

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.

Just as an experiment, I want everyone on this thread to think back to the last time you connected over SSH to a new computer on a company network. Did you check to make sure that the key that popped up was correct, or did you just hit accept?

This is why signing packages will not be a silver bullet that significantly reduces these kinds of attacks. Devs will still have their keys compromised, users will still ignore warnings that keys have changed. It's worth doing, but I am skeptical that it will eliminate these attacks.

In the Javascript world, we got malware recently that was the result of a dev voluntarily giving control of a package to another person. Signing isn't going to help with that.

My vote is on permissions and sandboxing. I think that sandboxing scales reasonably well since it can be applied to dependencies of dependencies all the way down your entire chain. I think that (unlike with phones) most dependencies don't require stuff like File I/O or Networking, which would eliminate a large number of attacks.

And importantly, I think that sandboxing acknowledges that trust is not binary. The big problem with signing packages is that it's following this outdated model of, "well, you'll either trust a package completely or you won't." The reality is that there are packages and package authors that you trust to different degrees and in different contexts. Many buildings have locks inside of them as well as outside, because trusting someone enough to come into your office is not the same as trusting them to root through all of your filing cabinets.

I don't think efforts around verifying authors/updates are useless, but they do often fail to take this principle into account.

Re: Strong_password Rubygem hijacked

#43

Post by alister »

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.

It seems to do that too (comparing against a list of the top 500 passwords):

https://github.com/bdmac/strong_password/blob/master/lib/str...

Re: Strong_password Rubygem hijacked

#44

Post by zbentley »

PeterisP wrote: post #18
msbarnett wrote: post #8

Earlier quoted context omitted.

Sure, obviously reinventing as many wheels as possible will minimize your exposure to third-party malfeasance. As in all forms of engineering there are, of course, no absolutes, only trade-offs to be made. The more wheels you reinvent, the slower your velocity for solving the core business problems that pay your bills. Moving too slowly can be fatal to the business. It’s a tricky balance. Signing isn’t perfect, but i…

It's not about the amount of functionality shifted to dependencies, but about the fragmentation of these dependencies. Packaging and distribution of libraries takes effort to do it properly, so they're only done properly if it's sufficiently centralized. If you have to import fifty third-party wheels, then it's unavoidable that some or most of these wheels can't be managed properly, but it's quite feasible to have a…

> If you want to have reliable dependencies then you eithery have to choose only dependencies with buraucratic and pedantic release governance, or manage/audit each dependency yourself

That's a false dichotomy. There are middle grounds which can and do work at scale:

Upgrade knowingly and deliberately (don't just spray greenkeeper everywhere).

Carefully monitor changed application/network behavior after upgrades.

Devote a manageable, non-zero amount of time to reading/finding security bulletins or security incidents on your most-heavily-used dependencies.

Pay attention to issue reports and prioritize any with possible security implications.

...and (at a slightly larger scale) hire, empower, and compensate people to do those kinds of things in a systematic, regular way.

Seriously, security engineering isn't served well by "ZOMG NPM is garbage we must switch to $megaframework and pray that their release engineers get everything right" hysteria and absolutism. There are effective, moderate strategies that help with these issues every day.

Re: Strong_password Rubygem hijacked

#45

Post by danShumway »

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…

It's also worth noting that under this system, if you trust a large library like React, but don't trust its dependencies, you might still trust that React is sandboxing its own imports correctly -- and then you could "inherit" React's permissions and be fine without overriding anything.

If you're really worried, then you still could go over your entire tree and override the default settings. But there's nothing that would mean you would be required to do that.

People are thinking about this using the phone/website model, where permissions are only applied at one level. With dependencies, whatever giant framework that you're pulling in could be using the same permissions system to secure its own dependencies, which would make you significantly safer.

Under the current system, you have to hope that none of the authors in your dependency chain make a mistake and get compromised. If everybody can sandbox anything, then you only have to hope that most of those authors don't make a mistake.

If somebody attaches malware to a dependency of a dependency, and if even one person along that chain is following best practices and saying, "yeah, I don't think this needs a special permission", then they've likely just prevented that attack from affecting anyone else deeper down the dependency chain.

Sandboxing in package managers is something that could actually scale pretty well; much better than it does for websites/phones/computers.

Re: Strong_password Rubygem hijacked

#47

Post by bigcostooge2 »

msbarnett wrote: post #38
bdcravens wrote: post #36

Earlier quoted context omitted.

> 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 late…

I work in finance and almost no project has a lock file. Unlocked dependencies everywhere.

Re: Strong_password Rubygem hijacked

#48

Post by cyphar »

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.

Or, alternatively, switching to the haveibeenpwned API[1] or zxcvbn[2].

[1]: https://haveibeenpwned.com/API/v2 [2]: https://github.com/dropbox/zxcvbn

Re: Strong_password Rubygem hijacked

#49

Post by oomkiller »

There's still a lot to learn about this incident, but most likely the RubyGems account was compromised, allowing the attacker to upload whatever they wanted. Signed releases with a web of trust would be ideal, but I doubt we'll ever see that world. A simple and pragmatic solution would be to have the next version of bundler support the ability to only install packages published with 2 factor enabled, then the next major rails version default it to on, with plenty of advanced warning in 6.x/bundler. This still has plenty of gaps, such as an attacker being able to take over even with 2 factor, and then re-enabling it with their own keys, or RubyGems.org itself being compromised. It still represents a major upgrade in security for the entire Ruby ecosystem without causing much pain to authors and users.

Re: Strong_password Rubygem hijacked

#50

Post by javagram »

zbentley wrote: post #44
PeterisP wrote: post #18

Earlier quoted context omitted.

It's not about the amount of functionality shifted to dependencies, but about the fragmentation of these dependencies. Packaging and distribution of libraries takes effort to do it properly, so they're only done properly if it's sufficiently centralized. If you have to import fifty third-party wheels, then it's unavoidable that some or most of these wheels can't be managed properly, but it's quite feasible to have a…

> If you want to have reliable dependencies then you eithery have to choose only dependencies with buraucratic and pedantic release governance, or manage/audit each dependency yourself That's a false dichotomy. There are middle grounds which can and do work at scale: Upgrade knowingly and deliberately (don't just spray greenkeeper everywhere). Carefully monitor changed application/network behavior after upgrades. Dev…

I think we can simplify that middle ground proposal down to two items:

1) only upgrade dependencies “knowingly and deliberately” (as the author of this article did). What does this mean if not auditing the upgrades? Just upgrading more rarely (e.g. because you know you need a specific feature or bug fix), but still auditing them? By waiting to upgrade, the diff will be vastly larger and performing an audit to “knowingly” upgrade will be much more difficult.

2) detecting a breach after you’ve already installed an attacker’s code onto your servers, via active monitoring or by hoping someone else does active monitoring or auditing and reports the issue to you or to a central authority.

#1 as a “middle ground” doesn’t seem too different from the post you responded to. #2 is what most projects seem to rely on - hope someone else finds the problem and reports it, and that they don’t get hit too hard in the meantime.

Post reply on HN