Recently the news broke that A critical vulnerability was identified in the package repository rubygems.org (the vulnerability is already cataloged under CVE-2022-29176), which allow without proper authorization, replace other people's packages in the repository by yanking 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, which made it possible to initiate the removal of external packages that match the part of the name up to the hyphen character.
En particular, in the controller code of the operation "yank", 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 remove.
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 the HackerOne bounty program for finding security issues in known open source projects.
The problem fixed at RubyGems.org on May 5 and according to the developers, have not yet identified traces of exploitation of the vulnerability in the logs for the past 18 months. At the same time, only a superficial audit has been carried out so far and a more in-depth audit is planned in 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 spoofing of hidden packages in continuous integration systems or when publishing projects, Developers are recommended to use Bundler with the options “–frozen” or “–deployment” to confirm dependencies.
Finally, if you are interested in knowing more about it, you can check the details in the following link