It was recently announced that a critical vulnerability was identified in the RubyGems.org package repository (the vulnerability is already cataloged under CVE-2022-29176), which allows , without proper authorization, the replacement of other people's packages in the repository by initiating the withdrawal (yank) of a legitimate package and uploading another file with the same name and version number in its place.
It is mentioned that the vulnerability is due to a bug in the "yank" action handler , which treats the part of the name after the hyphen as the platform name, making it possible to initiate the removal of external packages that match in the part of the name up to the hyphen character.
In particular, in the code of the "yank" operation handler, the call 'find_by!(full_name: "#{rubygem.name}-#{slug}")' was used to search for packages, while the "slug" parameter was passed to the package owner to determine the version to be removed.
The owner of the "rails-html" package could have specified "sanitizer-1.2.3" instead of the "1.2.3" version, which would cause the operation to apply to the "rails-html-sanitizer-1.2.3" package ″ from someone else. »
A security advisory for Rubygems.org was published yesterday.
The advisory concerned a bug that allowed a malicious user to mine certain gems and upload different files with the same name, version number, and different platform.
Let's take a deeper look to see what went wrong while going through the extraction process. As a pretext, let's imagine a scenario where we create a gem called "rails-html" with the intention of gaining unauthorized access to the widely used "rails-html-sanitizer" gem.
It is mentioned that three conditions must be met in order to successfully exploit this vulnerability:
- The attack can only be performed on packets that have a hyphen character in their name.
- An attacker should be able to place a gem pack with part of the name up to the hyphen character. For example, if the attack is against the "rails-html-sanitizer" package, the attacker must put their own "rails-html" package in the repository.
- The attacked package must have been created in the last 30 days or not updated for 100 days.
The problem was identified by a security researcher as part of HackerOne's bounty program to find security issues in well-known open-source projects.
The issue was fixed on RubyGems.org on May 5th , and according to the developers, they have not yet identified any traces of exploitation of the vulnerability in the logs over the past 18 months. However, only a superficial audit has been conducted so far, and a more in-depth audit is planned for the future.
At present, we believe that this vulnerability has not been exploited.
RubyGems.org sends an email to all gem owners when a gem version is released or removed. We have not received any support emails from gem owners stating that their gem has been mined without authorization.
An audit of gem changes over the last 18 months found no examples of malicious use of this vulnerability. Further auditing for any possible use of this exploit found no instance of this exploit being used to take over a gem without authorization in the history of RubyGems. We can't guarantee it never happened, but it doesn't seem likely.
To verify your projects, it is recommended to analyze the history of operations in the Gemfile.lock file Malicious activity is expressed in the presence of changes with the same name and version, or a platform change (for example, when a package xxx-1.2.3. 1.2.3 is updated to xxx-XNUMX-xxx).
As a solution against the impersonation of hidden packages in continuous integration systems or when publishing projects, developers are advised to use Bundler with the "--frozen" or "--deployment" options to confirm dependencies.
Finally, if you are interested in learning more about this , you can find the details at the following link.