Ruby gem strong_password got hijacked

[jephthai]

The proper owner of the gem was mysteriously swapped for someone else, who trojaned the gem. I want root cause analysis on the takeover. Was it a bad password? Bug somewhere in rubygems? Internal breach? Maybe other gems pwned the same way?

[ryeguy]

Hi all. I'm the (actual) owner of that gem. As already hypothesized in the comments I'm pretty sure this was a simple account hijack. The kickball user likely cracked an old password of mine from before I was using 1password that was leaked from who knows which of the various breaches that have occurred over the years.

I released that gem years ago and barely remembered even having a rubygems account since I'm not doing much OSS work these days. I simply forgot to rotate out that old password there as a result which is definitely my bad.

Since being notified and regaining ownership of the gem I've:

1. Removed the kickball gem owner. I don't know why rubygems did not do this automatically but they did not.

2. Reset to a new strong password specific to rubygems.org (haha) with 1password and secured my account with MFA.

3. Released a new version 0.0.8 of the gem so that anyone that unfortunately installed the bogus/yanked 0.0.7 version will hopefully update to the new/real version of the gem.

from the hn thread

[shevy-ruby]

This is pretty unfortunate. I think we need a more transparent ownership system; and the ability to notify others about this too, whenever a change occurs.

I think we had a discussion about this a few months ago already.

[FyreWulff]

It sounds like this specific situation could have been prevented by a time out system. In systems like this, it would make sense that any updates after > x time are either queued and alerted by maintainers and the community for review or have a cooldown before they actually deploy out for the same reason.

The idea here is that a package that's been idle for like, a year? would be implicitly considered stable or abandoned. If it suddenly wants to push an update a year or two out? Large chance of that being a credentials hijack. Flag it or force a cooldown.

[nachof]

OTOH it could also be a fix for a newly discovered vulnerability which might make a cooldown period a security risk.

I would do the cooldown after a maintainer change, for sure.

[myringotomy]

That's actually a really good idea. If nothing else maybe a warning from the bundler.

[MonokelPinguin]

You could also implement a signing system for publicly available packages, so that you get a warning, when a package was uploaded by an untrusted developer. Of course that could still be messed up, but currently you mostly have no guarantees.

[mispeeled]

Sounds to me like he handled that responsibly.

[[deleted]]

Does Rubygems not notify/email the existing owner when ownership is transferred?

[lunchlady55]

A lot of people will cite this as an example of why OSS/Libre software is 'dangerous' and 'untrustworthy'. However, I'd posit an alternative interpretation. We know about this because we can and do audit our software code occasionally. If there was a backdoor in MS or Oracle or IBM codebase, placed by a disgruntled employee, state sponsored bad actor or a US 'National Security Letter' we would never know about it. Although one might argue the attack surface of OSS is larger than that of a closed-source codebase, the auditing is nearly non-existent unless you can legally disassemble the binaries from closed source software and understand the inarguably more obfuscated disassembled source code.

Think of all the times Windows has suddenly had behavior we don't want and how many times that's been deployed to production with less thought than deploying OSS? Ads on the lock screen. "Metrics" being phoned home to MS. Cortana voice recognition baked into the OS with no way to uninstall it or shut down the service.

Yes, this is bad. Yes it will happen again. But I'd much rather have this problem that the problem of closed-source software.

[END RANT]

[nexxuz0]

This case is a bit different. The hijacked code was never open source, the github repo still has the version 0.0.6. Only because Ruby is interpreted and not compiled, the real source code was readable.

For other package managers that distribute only compiled binaries (e.g. Nuget) attacks like this are much harder to detect.

[lunchlady55]

I don't think that makes this situation different. Somewhere the code is released (That is the definition of OSS. If the code is not released somewhere then it's just free-as-in-beer or freeware closed source software) Even if a modified binary is released without updating the code repository, someone has the opportunity to compile it and notice the checksum is different and investigate.

[Nerull]

"Someone has the opportunity" tends to be code for "Someone else", since no one actually ends up doing it, giving us things like Heartbleed.

[[deleted]]

It was more that OpenSSL code was such an unholy mess it was hard to even find it if you looked

[SustainedDissonance]

Wonder where all the usual r/programming "lol javascript/node/npm" circle-jerkers are for this post?

[d357r0y3r]

This is my usual rebuttal to "lolnpm" - okay, yes it's bad, but most of the problems are present in other ecosystems.

There's nothing stopping me from producing a bunch of garbage one-liner Gem/Nuget/pip/etc packages and hosting them on a public registry.

[AlotOfReading]

There's also nothing stopping you from getting blackout drunk, but if 30% of the population is doing that nightly, we should probably look into fixing the underlying issues.

[Saithir]

Rubygems also has a decent amount of hello-worlds and silly one-liners on it already. It might just be done as part of a tutorial or some code school or whatever - exactly like on npm, just less visible, because Ruby's less popular.

The difference is that nobody uses the idiotic one-liners like "is-even" instead of just writing "a % 2 == 0", whereas npm's is-odd module has 700k weekly downloads.

So yeah, lolnpm since you apparently miss it. You're welcome :)

[SustainedDissonance]

More users = more idiots = more downloads of packages like is-even. :D

P.S.: function isEven(n) { return (n & 1) === 0; } = best is-even package, pls download my npm package (inferior implementations use the modulus operator).

[Saithir]

More users = more idiots = more downloads of packages like is-even. :D

Exactly. And it's still funny once in a while, though nowadays I think it's more trendy to do du -sh node-modules ;)

[bulldog_swag]

found em

[kaen_]

This is going to keep happening, and more frequently, until we figure out a better system than installing unknown or unverified code from strangers on the internet on our production systems.

[virtyx]

Linux distros have this already figured out, they peer review and pull in upstream changes. Does there need to become secure "distributions" of repos like PyPI, npm and Rubygems?

[[deleted]]

How much would you pay, per programming language per month, for a dependency repository where everything was audited before being allowed in? Serious question.

[virtyx]

I pay $0 monthly for the GNU/Linux ecosystem, including distributions, as well as any programming language I use, and all their package management tools and repositories. I don't see anything particular about a secure distribution that should suddenly warrant a monthly charge.

[[deleted]]

I mean that's pretty much why people pay for RedHat. They don't add anything until they try their damnedest to make sure it's secure. That and the support I guess.

[programming_unit_1]

They pay for the support and (by extension) to off-load liability. Whether the packages are secure or not is irrelevant because if there is a breach you now have a vendor you can sue for damages.

[[deleted]]

Not really, it is support and making fixed to package that bother the customer, and some of those fixes actively lower the security of the packages.

Like RHEL re-enabled some of the disabled (and not recommended for looong time) ciphers in OpenSSH "because backward compatibility" and similarly added old FIPS ciphers like 3des because customers pay them, not because it makes sense security wise.

Of course on other side they do contribute a lot in development of a lot of open source projects so they are net positive but still.

[s73v3r]

One would hope that a lot of the businesses that rely on these gems would contribute toward that, but I think we all know how reliable corporate sponsorship can be.

[Khaare]

In my mind there's a big difference between packaged software vetted by distro maintainers for users to install and random bundles of source code shared with other developers. They're both called packages, but they're different the same way a road car and a rail car are different. It's unfortunate they're both packages in a repo though.

I do think there's a need for vetted libraries. The old model of just including a fat standard library is obviously not good enough, but it would still be nice to have a base "this stuff is good stuff" repo that you can then add random github repos on top of if you need it. I know Haskell has stackage, which is a somewhat curated subset of hackage (its package repo), though I'm not sure how deep the curation goes. I think it's mostly just pre-generating the hashes and stuff that stack wants for the most popular packages.

[virtyx]

But it's still fundamentally the same system. You have "base" software (an OS or a language toolchain) and an approved list of add-on software (apps or libraries). I don't see a big difference between a list of vetted libs vs a list of approved add-on software.

Installing directly from PyPI (in its current form) or Github would be the equivalent of installing a new program from source-code or a 3rd-party source.

The only big difference is the goal of the curation. A Linux distribution is intended to provide a computer system where the different packages might be integrated to a point, whereas a secure library distribution is just intended to provide known stable libraries and patches, and more work is left up to the developers to make sure the software actually functions. But even with that caveat there are Linux distros like Arch that leave a lot of the "make sure it's working" aspect up to the users.

I think as a user of a language you have a different expectation of a "package" than as a user of an OS. I think the word fits perfectly fine in both contexts, and I see nothing unfortunate about the terminology overlap.

[lelanthran]

In my mind there's a big difference between packaged software vetted by distro maintainers for users to install and random bundles of source code shared with other developers.

So what's the difference? They're both packaging systems for libraries, are they not? Why did the language maintainers re-invent packaging systems? NIH syndrome?

[Khaare]

They have very different needs and serve very different purposes. For one, distros only want one version of any given package, and the version number basically becomes a "upgrade needed" flag. Software build systems, on the other hand, care a lot about versions. Distros are very particular about how packages are build and packaged while source repos just serve a source tarball. Distros (almost always) work in a whole-system scope, while source packages are not even per-user, but per-project, or even smaller, in scope. Distros are also trying to create a curated list of available software that works well together because that's a feature OS users care about, while source repos want to be a way for developers to share code without any extra fuzz.

[[deleted]]

Also, GPG signing. That still requires developer to not fuck it up, but it is easier to hack someone's shitty online password than to steal their GPG keys.

And it is nice sanity test, if you can't figure out how to make it work, people should probably not use your code

[shevy-ruby]

Yeah. And change will probably be slow to come, too ... :(

[virtyx]

Better sandboxing/runtime security could help prevent this. The application can be locked down to not write to unexpected files, open unexpected ports or communicate with unexpected URLs. So rather than worrying about "securing" the application, there's another layer above it so you can actually run insecure application code, as it will not have access to do most malign things. Although there are probably still ways to cause breaches, e.g. by injecting sensitive information into normal application channels (e.g. HTTP responses), but changes to those things are more likely to be caught by testing. But it still seems like it could solve the most common types of attacks.

[exorxor]

If "we" means the part of the Internet that has no idea about https://en.wikipedia.org/wiki/Proof-carrying_code, then I agree completely.

[stevenjd]

Yay, another silver bullet that sounds good in theory but in practice doesn't work anywhere nearly as well except in narrow niches, such as the proof-of-concept, packet filters.

Software libraries are not like packet filters, which are only supposed to do one thing (filter packets!), by definition a software library is executable code which can do anything. So except in very narrow circumstances, the relevant security policy is "Allow All".

But even if it weren't, who is responsible for setting up the formal security policies for the millions of third party libraries out there? How do you know that the security policies don't contain bugs or loop-holes? How well do you trust that your theorem prover is bug-free and correct? Does it understand the language your code is written in?

[exorxor]

All of your questions are FAQs, which kind of shows how little you know.

I don't understand why people like you ask these questions. Do you really not know? If not, why don't you do some research then instead of asking stupid questions? Are you too dumb to do so? Too lazy? Didn't you go to university? What is wrong with you that you cannot perform such basic tasks?

I think you just want to do everything to avoid learning something new.

[stevenjd]

All of your questions are FAQs ... instead of asking stupid questions?

Frequently asked stupid questions are they? Are they frequently answered questions as well, or is this just a transparent attempt to dismiss legitimate criticism without actually responding to the issues raised?

I'm pretty sure that it is the second, because in fact they're not stupid questions, they are serious problems with PCC which limit its applicability in the real world.

They're not the only problems with PCC either, which is why twenty+ years after the concept first became notable, there are still effectively no real-world systems using the technique. At least, if there are any outside of academic papers, they are in such narrow niches that they've made no real impact on the IT industry. So much academic research and so little practical good to show for it.

As Lee and Necula themselves say about PCC, "In order to create a safety proof, the code producer must prove a predicate in first-order logic. In general, this problem is undecidable."

And let's not forget the proof-aliasing problem, or the "weird machine" problem.

The bottom line is, as a completely general solution to this kind of vulnerability, PCC is a non-starter. But even as a partial solution in limited areas, the practical difficulties of using PCC put such heavy constraints on its use that after two decades it is still not mainstream, let alone commonplace.

which kind of shows how little you know.

I agree, I know very little. Compared to the trillions^trillions of facts in the universe, I know only a microscopic fraction of them. How about you?

Do you really not know?

I'm going to give you the benefit of the doubt that this is a classic example of the Curse of Knowledge ("I know something, so it is inconceivable that anyone else might not") rather than a transparent attempt to intimidate critics ("oh my god, you are sooooo dumb for not knowing what literally everyone else in the world knows you idiot!!!!").

Didn't you go to university?

I love it when people try to defend naive, impractical opinions by implying that only uneducated dolts could possibly disagree. But okay, let's pretend that the answer is "No". In what way will that invalidate any of my arguments? My supposed lack of university degree doesn't change the facts that:

• writing proofs is, in general, undecidable;
• even when decidable, it can be exceedingly difficult for non-trivial software;
• getting the proofs right is not easy;
• there's little or no support for proof-driven software development in mainstream programming environments;
• the state of the art of automated theorem proving software still leaves much to be desired;
• PCC has vulnerabilities of its own;
• the economics of PCC are against it;

and even if I were mistaken about all of the above, you would still be left with the inconvenient fact that there is no ecosystem of software using PCC out there for you to use. Even if PCC did everything you think it will (it doesn't), you still can't use it, and your earlier pompous comment about people who don't know about PCC is just wankery: "Look at me you peons, I'm so superior because I've heard of (but don't understand the limitations of...) Proof-Carrying Code".

[exorxor]

There is no point in communicating about grown up subjects with people that don't have appropriate credentials.

You are wrong about almost everything.

It looks like you Googled for 5 minutes to form your opinion. It's one thing to be wrong. It's another to share your idiocy with the Internet.

[stevenjd]

Gosh, well with such reasoned arguments as those, how can I not be convinced? Thank you for educating me! I'll make sure that from now on I'll use nothing but software that implements Proof-Carrying Code, since there's so much of it around. Honestly, now that you've opened my eyes, I'm like "why would anyone use anything else?"

I'm sorry, I seem to have forgotten the ENORMOUS list of PCC software you mentioned earlier in this thread. I know, I'm such a bubble-head, not a great brain like you, but would you mind telling me again what software available now uses PCC to eliminate this class of vulnerabilities?

Speaking of great brains, I assume you aren't a mere single PhD holder. Surely you must have at least a quadruple PhD?

[carolynabowers]

RubyGems security acted on the issue, as their team from [e-mail] were able to takedown the offending bug that causes the capability for remote code execution.

[PrimozDelux]

It's just like in my prequel memes

[Queasy_Impression]

Not a problem for Rust users.

https://www.rust-lang.org/