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

91–100 of 133 posts

Re: Strong_password Rubygem hijacked

#91

Post by masklinn »

viraptor wrote: post #72
redsymbol wrote: post #64

Earlier quoted context omitted.

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

This discussion is basically inventing a per-library pledge(2).

Re: Strong_password Rubygem hijacked

#92

Post by chupasaurus »

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…

My bet goes to #3. After [0]this commit, everything is possible in Ruby world.

[0]https://github.com/rails/rails/commit/b83965785db1eec019edf1...

Re: Strong_password Rubygem hijacked

#93

Post by nurettin »

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…

Not sure why someone with malicious intent would use their rubygems superpower just to compromise a low profile gem like this. Perhaps it is a targeted attack at a certain website which may now be compromised and we are just seeing the tip of the iceberg.

Re: Strong_password Rubygem hijacked

#94

Post by viraptor »

masklinn wrote: post #91
viraptor wrote: post #72

Earlier quoted context omitted.

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.

This discussion is basically inventing a per-library pledge(2).

or apparmor, selinux, grsec, tomoyo, ... But those systems can't integrate into scripting language per-library use case without some serious thread / IPC overhead.

Re: Strong_password Rubygem hijacked

#95

Post by masklinn »

viraptor wrote: post #94
masklinn wrote: post #91

Earlier quoted context omitted.

This discussion is basically inventing a per-library pledge(2).

or apparmor, selinux, grsec, tomoyo, ... But those systems can't integrate into scripting language per-library use case without some serious thread / IPC overhead.

These others can achieve what's intended, but the entire flavour of the discussion is a dead ringer for pledge's purpose and interface, which is much simpler and very much internal to the software (a self-check of sorts).

Re: Strong_password Rubygem hijacked

#96

Post by xyz-x »

ryanlol wrote: post #87
danShumway wrote: post #42

Earlier quoted context omitted.

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…

>Did you check to make sure that the key that popped up was correct, or did you just hit accept? But if you had the key cached, and it changed, you’d probably freak out. >This is why signing packages will not be a silver bullet that significantly reduces these kinds of attacks. You’ve just isolated the impact of these attacks to new installs, how is that not significant?

> But if you had the key cached, and it changed, you’d probably freak out.

Not in the servers-as-cattle age. By default, a rebuilt server will have a new key. Otherwise, you'd have to save the server SSH key in your configuration/build files, and then you've moved what you have to protect to the source control of the servers, and probably exposed that secret key to many more people and developers than you would have done by leaving the key on the server.

Jumping one stratum forward, with hosted k8s you don't even know the host's key; you do everything via HTTPS and the almost globally accepted list of secure CA:s.

Re: Strong_password Rubygem hijacked

#97

Post by jakobegger »

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…

Or:

4. The maintainer of the gem is complicit in the attack, and transferred ownership voluntary.

Re: Strong_password Rubygem hijacked

#98

Post by klntsky »

Filligree wrote: post #59
nordsieck wrote: post #29

Earlier quoted context omitted.

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

If you're running Haskell. Few other languages can do it.

For reference:

https://downloads.haskell.org/~ghc/latest/docs/html/users_gu...

Re: Strong_password Rubygem hijacked

#99

Post by trickstra »

jakobegger wrote: post #97
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…

Or: 4. The maintainer of the gem is complicit in the attack, and transferred ownership voluntary.

Yes, we all remember Dominic Tarr's event-stream handover to an anonymous hacker because maintaining it "wasn't fun anymore" https://gist.github.com/dominictarr/9fd9c1024c94592bc7268d36...

Re: Strong_password Rubygem hijacked

#100

Post by OskarS »

trickstra wrote: post #99
jakobegger wrote: post #97

Earlier quoted context omitted.

Or: 4. The maintainer of the gem is complicit in the attack, and transferred ownership voluntary.

Yes, we all remember Dominic Tarr's event-stream handover to an anonymous hacker because maintaining it "wasn't fun anymore" https://gist.github.com/dominictarr/9fd9c1024c94592bc7268d36...

That's an extremely ungenerous interpretation of those events. He shouldn't have handed over control of the package to someone he barely knew, but from his perspective, it was that or let the package die. He volunteered his time, he had no kind of obligation to continue if he didn't want to. His actions were certainly not malicious, and he was clearly not "complicit" with the hacker, which is what you're implying.

That incident highlighted a broadly systemic problem with how these kinds of packages are maintained, it was not a case of "one bad maintainer".

Post reply on HN