Check your Gems: RubyGems Fixes Unauthorized Package Takeover Bug
The RubyGems package repository has fixed a critical vulnerability that would allow anyone to unpublish (“yank”) certain Ruby packages from the repository and republish their tainted or malicious versions with the same file names and version numbers.
Assigned CVE-2022-29176, the critical flaw existed on RubyGems.org, which is the Ruby-equivalent of npmjs.com, and hosts over 170,000 Ruby packages (gems) with almost 100 billion downloads served over its lifetime.
An initial audit from RubyGems reveals that the vulnerability has not been exploited within the last 18 months to alter any gems, but a deeper audit is still in progress with results yet to be announced.
Hijacking a gem: yank, alter, republish
This week, RubyGems announced that a critical bug could’ve enabled any RubyGems.org user to yank versions of a gem that they didn’t have authorization for, and replace the gem’s contents with newer files.
Also Read: Data Storage Security Standards: What Storage Professionals Need to Know
Similar to npm for NodeJS packages, RubyGems is a package manager for the Ruby programming language and provides a standardized format for distributing finished Ruby artifacts (called “gems”). The RubyGems.org registry is the community’s gem hosting service allowing developers to instantly publish or install gems and use a set of specialized APIs.
Should a threat actor become aware of such a flaw, they could quietly replace the contents of legitimate Ruby packages with malware—something which has echoes of npm’s popular ua-parser-js, coa, and rc libraries that were hijacked last year to distribute crypto miners and password stealers.
Although the npm hijacking incidents stemmed from maintainer account compromises rather than a vulnerability exploit, they wreaked havoc as libraries like ‘ua-parser-js’ have been used by over a thousand projects, including those used by Facebook, Microsoft, Amazon, Instagram, Google, Slack, Mozilla, Discord, Elastic, Intuit, Reddit, and many more well-known companies.
In Ruby’s case, mass exploitation of such an exploit could cause widespread damage to the Ruby ecosystem and overall software supply chain security.
To exploit the vulnerability, RubyGems explains, the following conditions need to be met:
- The gem being targeted has one or more dashes in its name, e.g. something-provider.
- The word that comes before the first dash represents an attacker-controlled gem that exists on RubyGems.org.
- The gem being yanked/altered was either created within the past 30 days or had not been updated in over 100 days.
“For example, the gem something-provider could have been taken over by the owner of the gem something,” explains RubyGems.
“Organizations with many gems were not vulnerable as long as they owned the gem with the name before the dash, for example owning the gem orgname protected all gems with names like orgname-provider.”
This vulnerability, assigned CVE-2022-29176, lurked in the “yank action” of RubyGems code and has now been fixed.
Independent developer and pentester, Greg Molnar has explained the flaw in a little more technical depth.
At this time, RubyGems.org maintainers do not believe the vulnerability has been exploited, according to the results of an audit that analyzed gem changes made over the last 18 months on the platform.
Also Read: IT Governance Framework PDF Best Practices And Guidelines
But the registry owners state that a deeper audit is ongoing and its results will follow in the security advisory published for this vulnerability, which also contains some mitigations.
“RubyGems.org sends an email to all gem owners when a gem version is published or yanked. We have not received any support emails from gem owners indicating that their gem has been yanked without authorization,” states the advisory.
RubyGem developers can audit their application history for possible past exploits by reviewing their Gemfile.lock and searching for gems that had their platform changed with version numbers remaining unchanged.
For example, seeing your gemname-3.1.2 gem renamed to gemname-3.1.2-java is one possible sign of the vulnerability having been exploited.
User laursisask has been credited with reporting the vulnerability via HackerOne.
May 8th, 5:17 PM ET: Added information on how to check if your gem has been exploited via this flaw.
May 8th, 5:35 PM ET: Added link to Molnar’s technical analysis of the flaw.