Ruby Fights Supply-Chain Attacks With Filter Offering 'Cooldown' Before Installing New Packages (rubygems.org) 24
Most supply-chain attacks using Ruby's package hosting site "exploit a narrow window," according to a new blog post form Ruby core maintainer Hiroshi Shibata.
So its packaging-managing Bundler tool now offers a filter that blocks new version until it's been public "for at least N days. Releases too new to have been scrutinized are passed over in favor of ones that have aged past the window." The feature was designed in the open, drawing on how other ecosystems approach the same problem. It is opt-in, and complements rather than replaces existing defenses like mandatory 2FA and trusted publishing... Cooldown is unset by default, so a project without it keeps resolving to the newest versions.... Passing 0 disables cooldown for the run...
Cooldown is most useful as one part of the wider security investment happening on rubygems.org. The registry now validates gem contents at push time and checks logins against Have I Been Pwned so that compromised passwords cannot be reused, work described in Protecting rubygems.org from the outside in. A dedicated team is running AI-assisted vulnerability scanning against the most critical gems, backed by Alpha Omega and Anthropic, and the direction of all of this is tracked on a public roadmap. Trusted publishing and mandatory 2FA already raise the bar for who can push a release in the first place.
So its packaging-managing Bundler tool now offers a filter that blocks new version until it's been public "for at least N days. Releases too new to have been scrutinized are passed over in favor of ones that have aged past the window." The feature was designed in the open, drawing on how other ecosystems approach the same problem. It is opt-in, and complements rather than replaces existing defenses like mandatory 2FA and trusted publishing... Cooldown is unset by default, so a project without it keeps resolving to the newest versions.... Passing 0 disables cooldown for the run...
Cooldown is most useful as one part of the wider security investment happening on rubygems.org. The registry now validates gem contents at push time and checks logins against Have I Been Pwned so that compromised passwords cannot be reused, work described in Protecting rubygems.org from the outside in. A dedicated team is running AI-assisted vulnerability scanning against the most critical gems, backed by Alpha Omega and Anthropic, and the direction of all of this is tracked on a public roadmap. Trusted publishing and mandatory 2FA already raise the bar for who can push a release in the first place.
And how will that help? (Score:2)
It just adds some latency. This will not fix the missing reviews or reputation checks.
Re:And how will that help? (Score:5, Interesting)
Well, it lets some people have long cooldowns make the rest of their ecosystem suckers.
Of course, this *also* means the people with high cooldowns get to be vulnerable to security problems longer because they will be applying cooldown to security fixes...
But yes, some sort of actual curation would be the best mitigation, particularly to allow trustworthy critical security updates through quickly instead of those getting caught in the cooldown.
Re: (Score:3)
A lot of supply chain attacks are compromised user accounts. So its not uncommon for that user, or someone else involved in the project to recognize an unexpected release. Generally it also gives a chance for security companies to detect malicious code.
Ironically of course it also slows down adoption of security fixes so as a developer you'll need to monitor for important disclosures.
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
You are hallucinating.
Re: (Score:3)
Will encourage sleeper attacks (Score:4, Insightful)
Re: (Score:2)
Indeed. With the xz attack we have seen that and if they had not been technologically incompetent, it would have worked. Such an attack is also not very expensive. An expert for a year full-time is maybe 200k, maybe less.
Re: (Score:2)
Indeed. With the xz attack we have seen that and if they had not been technologically incompetent, it would have worked.
They apparently rushed because additional protections were about to be put in place and they needed to get the exploit vector deployed before that happened. The lesson was the same as it always is, haste makes waste.
Such an attack is also not very expensive. An expert for a year full-time is maybe 200k, maybe less.
No one has officially identified the origin of the xz exploit attack, but in any case, the exploit was long term and slow (so as not to arouse suspicion), so not even full time effort (and while some countries would pay more than $200K for a full time employee capable of such work, some countri
Re: (Score:2)
True, but in most cases, the malicious package is created by an attacker, side-stepping the original developer. When they realise they've been side-stepped, they take steps to resolve the problem and delete the malicious package - without even looking in it to see what it does. It doesn't take an actual exploit using the malicious package to trigger some sort of mitigation. That's a very different attack pattern to someone taking years to hit a specific target.
The likes of the cesspool of nodejs/npm could p
Learn to pin your dependecies (Score:4, Informative)
Just pin your dependencies. To an EXACT version, with a hash. No loose versioning or version auto-updates in the pipeline. Detect outdated versions automatically but update manually, after a full review, and a full av scan of the built environment before the release. Know and control what goes into the production environment. In other words, you're a professional - act like it.
Re: (Score:2)
If you download your dependencies at compile-time, you are already screwed. The only protection is local copies of older versions.
Re: (Score:3)
Agreed, but in practice it requires all your dependencies to do the same. All it takes is one of them to have a missing version and you'll go pulling it in at 'latest'. You can freeze it at that point for your subsequent deploys, but it'll still have shafted you in dev while you were revving some version or other.
Strictly freezing versions of the entire dependency tree is probably the best method there is, but it sure adds to the management overhead. You've still got to vet every single dependency at the ve
Re:Learn to pin your dependecies (Score:4, Interesting)
IMHO, this is why the industry moved to vendor maintained software repositories with signed code and such - rpm/yum, deb/apt, etc..
The central place does the vetting, and you get the latest stable version. Something needs a hot fix? They push it out, and you install on your own security updates schedule. And it should be ensuring they maintain backward compatible API's / ABI's, pushing major version changes to new packages if needed (ex. keepass / keepass2).
Requiring everyone that (builds and) installs your node based app to pull down all the libraries from NPM bypasses the package management provided by the system and vendor. You are instead trusting the myriad of NPM devs to all maintain security and trust. In addition, they often install to virtual roots, so you wind up with a bunch of the same code installed in numerous places with various versions in each - how is that easier to maintain (outside of development)?
RE: devslash0's suggestion to pin all dependencies... that's distributing the hard part to the endpoints (us people). It _IS_ a solution to the current NPM setup, but it just highlights how bad it is.
Re: (Score:2)
Have fun in the node/python/ruby ecosystems. It's not like C++ where you have three big libraries, but you pull in hundreds of small packages. Update one dependency version and you have to recursively review 50 others.
Re: (Score:2)
Just pin your dependencies. To an EXACT version, with a hash. No loose versioning or version auto-updates in the pipeline. Detect outdated versions automatically but update manually, after a full review, and a full av scan of the built environment before the release. Know and control what goes into the production environment. In other words, you're a professional - act like it.
Two years from now when said professional is dealing with the seventh AI-crafted zero-day fuckware attack of the day, how exactly will one be expected to 'act like it' in order to sustain system defenses and sanity?
You really think manual mode is going to be the answer? As if the email spam problem didn't grow exponentially.
The state of Ruby supply chain security (Score:5, Informative)
Re: (Score:2)
Indeed. What they are doing does not work and cannot work. The only thing that saved them up to now is an absence of attackers. With AI, that is going to change as now the technologically incompetent can do it as well on high amateur level. Which the highest level LLM-type AI can perform at, but which is plenty for the low amateur level "security" the defenders are using here.
Looks like amateur hour in software is slowly coming to a close. Good.
Re: (Score:2)
Spoken like a full-on cretin. Well done, you case makes sooooo much sense now!
Re: (Score:1)
Not a web dev in any way..... but Ruby has at least some use? The solution tells me usage is not extensive and if it works a comfortable little niche is reinforced.
Accountability. (Score:2)
The problem with this approach is, it only works as long as someone does the checking. In practice everyone turns on 'safe update channel' and nobody actually tests the bleeding edge, ten days elapse, and the malicious code flows into the 'safe channel'.
It is like sending for help in a first-aide situation, you need to point at someone specifically, make eye contact and say "YOU! go get help" if you just shout 'someone get help' and go back to recuse breathing or whatever you're occupied with everyone will
Remotely downloaded code (Score:2)
What, exactly, is the point or purpose of including code in your program that is downloaded from a third-party website every time you execute the program?
If you want to include a function or subroutine or library in your program, why wouldn't you just download it and use that?
"Lets drag in random code every time we run the program" is a huge security hole on its own and I genuinely don't understand why anyone would do that, or would even consider it as a worthwhile idea.
Ok, you can "pin it". Which still le