5 ms·

Cooldown Support for Ruby Bundler

169 points by calyhre 4mo ago

delichon 4mo ago
> 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?
- OptionOfT 4mo ago
  Can you in your own gem depend on gems from another server? Or does it need to be configured on the client? If not, and the current defacto standard gem server doesn't accept v1 anymore, we're good I suppose?
- werdnapk 4mo ago
  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 trusted (if they're your own) or already under some scrutiny and extra care already being taken (ideally), but this last case applies to very few projects I'm sure.
  - tenderlove 4mo ago
    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.
swader999 4mo ago
Aren't we back to the drawing board once everyone uses this?
- ihumanable 4mo ago
  Yea, all the new advice around using dependency cooldowns only works if _someone_ is installing these things before you and finding the vulnerabilities. It seems like the advice right now is to become a freerider while there are still people installing closer to release that will do free work for you finding out there's something nasty in the release. Once everyone is waiting 2 weeks to install an update, then the value of everyone waiting goes down dramatically.
  - kbenson 4mo ago
    This is how a chunk of people function anyway. There are plenty of people that choose to not install "point zero" release for software of a certain importance, assuming with any major changes there are often bugs that come along with it. In this case, since the number of cool down days is configurable, even if everyone was using it we would still likely see a somewhat smooth curve for adoption, since not everyone will choose the same delay and the delay time will likely map closely to how people want to habdke risk. It's all a trade off, just like it's always been. This just makes it simpler to act on what you want your risk/comfort level to be.
  - postalcoder 4mo ago
    Using dependency cooldowns is not a free-rider problem. There's a real tradeoff here – ppl are trading their time preference for security. Just as users are incentivized to avoid malware, researchers and attackers are equally motivated to be the first to discover it. The concern trolling around widespread dependency cooldowns doesn't make sense. Most people shouldn't be eager to download a release that hasn't made its way through at least some scans.
- password4321 4mo ago
  The point is to allow the automated scanners a chance to run. Every security company and their cousin wants to be the one to find the next big dependency malware.
doctorpangloss 4mo ago
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?
- trevor-e 4mo ago
  it specifically addresses this in the "The escape hatch" section...
  - k3nx 4mo ago
    So, the threat actor now, after making the compromise, just needs to announce that the previous version has a 0-day, and folks need to install the latest version? I love the idea of a cool down, but it can still be thwarted. I would just hope folks that are trying to patch a 0-day take extra caution to vet the new version. I wouldn't be opposed to a --cooldown 0 doing a side by side diff. I may not know what's going on in the code, but a 0-day shouldn't be a ton of new code either.
- deleted 4mo ago
  [deleted]
- esafak 4mo ago
  Security updates bypass the cooldown.
  - doctorpangloss 4mo ago
    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...
tancop 4mo ago
[dead]
shevy-java 4mo ago
Meanwhile ruby is dropping ranks. How active is rubygems.org itself? I retired when the 100k download threshold was installed onto developers there; on github I don't have any such restriction pertaining to code I publish and maintain. But even before that restriction, numerous gems were abandoned. I understand that this is a natural cycle anyway, but without an influx of new developers, ruby will fossilize and age out just as perl did before. None of those "cooldowns" will bring in new developers either. It all seems to be about meta-appeasing companies; this could indirectly help, but I doubt it will help much.
ashishb 4mo ago
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.
- woodruffw 4mo ago
  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.
- eranation 4mo ago
  So. Dependabot (and renovate) do have "cooldowns" supported, just need to set them up. For dependabot it's as simple as cooldown.default-days: 1 There are security researchers (that don't have cooldowns) that usually detect compromises within hours or less, and package managers almost always manage to remove the offending versions in less than 24 hours (usually much less). So people will 24 hours cooldowns get protected. Shameless plug: I maintain depsguard.com that tries to simplify cooldowns setup across anything that supports it, in one command (it scans from where you run it, e.g. if you run it from your user folder it will look for any local repos with dependabot / renovate and suggest a change.
  - ashishb 4mo ago
    > For dependabot it's as simple as > cooldown.default-days: 1 Most people stick to default of 0. In fact, I am realizing over time that it is best to make it 7-14 days.
eranation 4mo ago
Awesome! Will add it to depsguard.com this weekend.

169 points by calyhre 4mo ago

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

OptionOfT 4mo ago
Can you in your own gem depend on gems from another server? Or does it need to be configured on the client? If not, and the current defacto standard gem server doesn't accept v1 anymore, we're good I suppose?
werdnapk 4mo ago
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 trusted (if they're your own) or already under some scrutiny and extra care already being taken (ideally), but this last case applies to very few projects I'm sure.
- tenderlove 4mo ago
  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.

swader999 4mo ago

Aren't we back to the drawing board once everyone uses this?

ihumanable 4mo ago
Yea, all the new advice around using dependency cooldowns only works if _someone_ is installing these things before you and finding the vulnerabilities. It seems like the advice right now is to become a freerider while there are still people installing closer to release that will do free work for you finding out there's something nasty in the release. Once everyone is waiting 2 weeks to install an update, then the value of everyone waiting goes down dramatically.
- kbenson 4mo ago
  This is how a chunk of people function anyway. There are plenty of people that choose to not install "point zero" release for software of a certain importance, assuming with any major changes there are often bugs that come along with it. In this case, since the number of cool down days is configurable, even if everyone was using it we would still likely see a somewhat smooth curve for adoption, since not everyone will choose the same delay and the delay time will likely map closely to how people want to habdke risk. It's all a trade off, just like it's always been. This just makes it simpler to act on what you want your risk/comfort level to be.
- postalcoder 4mo ago
  Using dependency cooldowns is not a free-rider problem. There's a real tradeoff here – ppl are trading their time preference for security. Just as users are incentivized to avoid malware, researchers and attackers are equally motivated to be the first to discover it. The concern trolling around widespread dependency cooldowns doesn't make sense. Most people shouldn't be eager to download a release that hasn't made its way through at least some scans.
password4321 4mo ago
The point is to allow the automated scanners a chance to run. Every security company and their cousin wants to be the one to find the next big dependency malware.

doctorpangloss 4mo ago

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?

trevor-e 4mo ago
it specifically addresses this in the "The escape hatch" section...
- k3nx 4mo ago
  So, the threat actor now, after making the compromise, just needs to announce that the previous version has a 0-day, and folks need to install the latest version? I love the idea of a cool down, but it can still be thwarted. I would just hope folks that are trying to patch a 0-day take extra caution to vet the new version. I wouldn't be opposed to a --cooldown 0 doing a side by side diff. I may not know what's going on in the code, but a 0-day shouldn't be a ton of new code either.
deleted 4mo ago
[deleted]
esafak 4mo ago
Security updates bypass the cooldown.
- doctorpangloss 4mo ago
  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...

tancop 4mo ago

[dead]

shevy-java 4mo ago

Meanwhile ruby is dropping ranks. How active is rubygems.org itself? I retired when the 100k download threshold was installed onto developers there; on github I don't have any such restriction pertaining to code I publish and maintain. But even before that restriction, numerous gems were abandoned. I understand that this is a natural cycle anyway, but without an influx of new developers, ruby will fossilize and age out just as perl did before. None of those "cooldowns" will bring in new developers either. It all seems to be about meta-appeasing companies; this could indirectly help, but I doubt it will help much.

ashishb 4mo ago

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.

woodruffw 4mo ago
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.
eranation 4mo ago
So. Dependabot (and renovate) do have "cooldowns" supported, just need to set them up. For dependabot it's as simple as cooldown.default-days: 1 There are security researchers (that don't have cooldowns) that usually detect compromises within hours or less, and package managers almost always manage to remove the offending versions in less than 24 hours (usually much less). So people will 24 hours cooldowns get protected. Shameless plug: I maintain depsguard.com that tries to simplify cooldowns setup across anything that supports it, in one command (it scans from where you run it, e.g. if you run it from your user folder it will look for any local repos with dependabot / renovate and suggest a change.
- ashishb 4mo ago
  > For dependabot it's as simple as > cooldown.default-days: 1 Most people stick to default of 0. In fact, I am realizing over time that it is best to make it 7-14 days.

eranation 4mo ago

Awesome! Will add it to depsguard.com this weekend.