Unauthorized gem takeover for some gems · Advisory · rubygems/rubygems.org · Git...

Impact

Due to a bug in the yank action, it was possible for any RubyGems.org user to remove and replace certain gems even if that user was not authorized to do so.

To be vulnerable, a gem needed:

• one or more dashes in its name
• an attacker-controlled gem with the name before the dash
• creation within 30 days OR no updates for over 100 days

For example, the gem something-provider could have been taken over by the owner of the gem something. 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.

At present, we believe this vulnerability has not been exploited.

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.

An audit of gem changes for the last 18 months did not find any examples of this vulnerability being used in a malicious way. A deeper audit for any possible use of this exploit is ongoing, and we will update this advisory once it is complete.

Mitigations

Using Bundler in --frozen or --deployment mode in CI and during deploys, as the Bundler team has always recommended, will guarantee that your application does not silently switch to versions created using this exploit.

To audit your application history for possible past exploits, review your Gemfile.lock and look for gems whose platform changed when the version number did not change. For example, gemname-3.1.2 updating to gemname-3.1.2-java could indicate a possible abuse of this vulnerability.

Patches

RubyGems.org has been patched and is no longer vulnerable to this issue.

References

https://hackerone.com/bugs?subject=rubygems&report_id=1559856

tl;dr

A bug allowed anyone to yank certain gems and upload different files with the same name, same version number, and different platform. To verify your own app, check your Gemfile.lock history for changes that keep the same name and version number but add or change a platform. We have patched the bug, and found no malicious code uploaded using this vulnerability in the last 18 months of gem yanks and pushes.