by Paul Ducklin
Popular package management site RubyGems.org, which stores and supplies hundreds of thousands of modules for the widely-used programming language Ruby, just patched a dangerous server-side vulnerability.
The bug, dubbed CVE-2022-29176, could have allowed attackers to remove a package that wasn’t theirs (yanking it, in RubyGems jargon), and then to replace it with modified version of their own.
Fortunately, the RubyGems team has looked through its logs for the past 18 months, and says that it “did not find any examples of this vulnerability being used in a malicious way.”
We assume that the vast majority of package updates on record would involve a change in version number (given that when legitimate software changes, you need some obvious way of telling the new version from the old one), which would make the yank-and-republish process rather rare.
If, indeed, there were only a few cases to review, we also assume that it would be feasible to compare any changes between the now-defunct “yanked” code and the newly republished code, even in a repository as large as RubyGems.
This suggests that any unusual rip-and-replace operations would indeed have been found during the security review that followed the report of the bug.
Additionally, the RubyGems security bulletin notes that package owners receive an automatic email notification whenever a package of theirs is yanked or published, yet no support tickets were ever received to report peculiar and unexpected changes of this sort.
Ironically, however, this rip-and-replace bug only works on packages created within the last 30 days, or on packages that haven’t been updated for more than 100 days. (No, we don’t know why these curiously specific limitations apply, but apparently they do.)
In other words, one class of vulnerable package includes all those that aren’t being actively developed any more, thus making it more likely that the email address for the package would be out-of-date or no longer monitored. Read More
