Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cooldown Support for Ruby Bundler

blog.rubygems.org

Post reply on HN
Print view View original

31–40 of 46 posts

Re: Cooldown Support for Ruby Bundler

#31

Post by tenderlove »

werdnapk wrote: post #9
delichon wrote: post #2

> A version whose source does not expose created_at, such as older gem servers, historical entries from before the v2 cutover, or private registries still on the v1 format, is treated as outside the window and stays resolvable. How is that not an easy exploit to circumvent the cooldown?

Most gems in Ruby/Rails projects come from rubygems, so if they were published long ago, any exploits should have already been found hopefully. Any old gems that would attempt to release a new compromised version would now get a created_at timestamp and the cooldown applies. Unless you can compromise the gem server to overwrite created_at fields, I don't see any exploits here. Private gem servers are either already t…

RubyGems.org backfilled older releases with `created_at` fields, so theoretically you could still do the cooldown with very old gems (though I don't know why you would). It's only private / alternative gem servers that may not provide `created_at` fields.

Re: Cooldown Support for Ruby Bundler

#32

Post by weaksauce »

teeray wrote: post #23
weaksauce wrote: post #22

Earlier quoted context omitted.

security researchers not the ones shipping the faulty code.

We’re not talking about security researchers here: > there is lots to gain from being the first to write about the new malware on some registry, so *companies* are actively downloading and inspecting literally every package. (Emphasis mine)

yeah security researchers at security companies are the ones we are talking about.

Re: Cooldown Support for Ruby Bundler

#33

Post by nixpulvis »

weinzierl wrote: post #26
grncdr wrote: post #7

Earlier quoted context omitted.

I think the idea is that dedicated security firms and/or automated scanners will discover exploits in the cooldown period.

If this is the idea, why don't we let the dedicated security firms and/or automated scanners find the vulnerabilities before the release? You need an early release in the "given enough eyeballs all bugs are shallow " world because you need the eyeballs, but if you count on specialists and scanners no general availability release is necessary and hence no cool down.

Because this isn't about guarding against general vulnerabilities. This is about guarding against a class of supply chain attack where an attacker compromises the packaging system in a way that they slip in a malicious release.

It is true if everyone waits a cooldown (I don't like this name, but that's another thing) period, then it doesn't solve anything, but as others have pointed out, just because you don't build off the cooldown doesn't mean you and others aren't watching the releases.

Closing the window makes the burden of hiding the exploit higher, which is I think objectively an improvement of security posture.

Re: Cooldown Support for Ruby Bundler

#34

Post by weinzierl »

john_strinlai wrote: post #28
weinzierl wrote: post #26

Earlier quoted context omitted.

If this is the idea, why don't we let the dedicated security firms and/or automated scanners find the vulnerabilities before the release? You need an early release in the "given enough eyeballs all bugs are shallow " world because you need the eyeballs, but if you count on specialists and scanners no general availability release is necessary and hence no cool down.

i am not sure what the benefits of your proposal are compared to the "cooldown period" way. the releases will be delayed for the same time period, but you increase the amount of coordination required significantly and reduce user agency.

Currently we release software to the public early and let people find vulnerabilities after release. A few early updaters get burned but the rest of us is saved. This cannot go on.

One idea to get out of this mess is to use cooldowns. But this idea only works if what GP said is true: Vulnerabilities are mostly found by (paid) specialists and advanced tools and not the general user populations.

My point is that, if that is true we do not need to release insecure software. Do the magic before the release and no one gets hurt.

Re: Cooldown Support for Ruby Bundler

#35

Post by AgentME »

weinzierl wrote: post #34
john_strinlai wrote: post #28

Earlier quoted context omitted.

i am not sure what the benefits of your proposal are compared to the "cooldown period" way. the releases will be delayed for the same time period, but you increase the amount of coordination required significantly and reduce user agency.

Currently we release software to the public early and let people find vulnerabilities after release. A few early updaters get burned but the rest of us is saved. This cannot go on. One idea to get out of this mess is to use cooldowns. But this idea only works if what GP said is true: Vulnerabilities are mostly found by (paid) specialists and advanced tools and not the general user populations. My point is that, if th…

We could rename "cooldown" to "pre-release period".

Re: Cooldown Support for Ruby Bundler

#36

Post by mike_hock »

woodruffw wrote: post #16
grncdr wrote: post #7

Earlier quoted context omitted.

I think the idea is that dedicated security firms and/or automated scanners will discover exploits in the cooldown period.

Yep, this is the thesis behind them. I wish people engaged more fully with this argument: it’s possible to believe that security vendors won’t do a good job of upholding their side of the bargain, but I’ve yet to see anybody argue that rather than making a faulty universalization argument against cooldowns.

Anything that isn't blatantly obvious zero effort malware is gonna wait for the cooldown to expire and then gradually introduce backdoors or vulnerabilities in subsequent versions once the project has gained trust.

Re: Cooldown Support for Ruby Bundler

#37

Post by woodruffw »

ashishb wrote: post #25

Hypothesis: a big accelerant of these rapid repository compromise (from Red hat to GitHub to Amazon to small startups) might be GitHub+dependabot automatic dependency updates. So, just like COVID-19 used air travel, modern malware attacks are relying on GitHub+dependabot to speed up the spread. Even for single page website built using Vue, I would get about 5 updates a week.

It’s plausible. It’s certainly the case that we (meaning security practitioners) spent years trying to move people onto faster and more automated update cycles, and these kinds of compromises have revealed a latent weakness that comes wit doing so.

Re: Cooldown Support for Ruby Bundler

#38

Post by woodruffw »

mike_hock wrote: post #36
woodruffw wrote: post #16

Earlier quoted context omitted.

Yep, this is the thesis behind them. I wish people engaged more fully with this argument: it’s possible to believe that security vendors won’t do a good job of upholding their side of the bargain, but I’ve yet to see anybody argue that rather than making a faulty universalization argument against cooldowns.

Anything that isn't blatantly obvious zero effort malware is gonna wait for the cooldown to expire and then gradually introduce backdoors or vulnerabilities in subsequent versions once the project has gained trust.

I think you’re talking about something different than the median case here: the kinds of malware that cooldowns are effective against are attacking already trusted projects, e.g. via repository compromise.

I think it remains to be seen whether the economics of this kind of “supply chain” compromise support a stealthier actor profile: the whole reason to compromise an OSS project rather than exploit a single victim’s browser or phone is to smash-and-grab en masse. That’s a fundamentally noisy and delay-sensitive attacker profile.

Re: Cooldown Support for Ruby Bundler

#39

Post by doctorpangloss »

esafak wrote: post #18
doctorpangloss wrote: post #12

you have 1.0 installed. you enable 7 day cooldowns. an exploit is discovered in 1.0, and 1.1 is immediately released to fix the exploit. do you sit on 1.0 for 7 days?

Security updates bypass the cooldown.

But what channel decides it is a security update? How do you know? Someone has to notify whom exactly? And what if the adversary says their supply chain attack commit is a security update?

All of this cooldown stuff is so mind bogglingly stupid...

Post reply on HN