Another day, another reminder to be careful about installing software downloaded from the Internet: This time, the warning is for the Ruby community.
The team behind closed two security flaws on its website that could be exploited by an attacker to replace any .gem file on the server with a different file having the same name, according to an advisory posted on the Ruby gem hosting service’s website.
Gems with a dash in the name (blank-blank) pushed to after June 11, 2014, when the flaw was introduced, were vulnerable to tampering.

The team verified every .gem file uploaded to the server after Feb 8, 2015, and didn’t find any cases of tampering, but recommended authors verify their gems as well.
“On April 2, 2016, the security team was made aware of a vulnerability that allowed an unauthorized user to update existing gem files for existing gem versions in certain circumstances…. Upon further examination we discovered another similar attack vector not fixed with the original patch,” David Radcliffe, the lead developer of the RubyGems infrastructure project, wrote in the advisory.
Authors should download and run the gem unpack command to inspect the content of their gems.

They should also run gem spec to look for any changes to the gemspec.

Gems that appear to have been modified should be removed from the service using gem yank and reported to the RubyGems security team.
No tampered gems found yet
The original reported vulnerability was introduced into the website on June 11, 2014, as part of a restructuring effort to handle Amazon S3 errors, and the second flaw has been “present since the beginning of,” Radcliffe wrote.

The team has fixed both issues and confirmed exploitation was no longer possible for either one.
The advisory also said there were no cases of gem files modified using the second vulnerability, but there was a possibility some files had been modified through the reported flaw. RubyGems started calculating SHA256 checksums on gems pushed to the service on Feb. 8, 2015, and was able to verify that none of those gems had been maliciously changed.

Gems pushed before Feb. 8, 2015, don’t have a calculated checksum, so the team can’t definitively tell if they have been modified.
Radcliffe and his team didn’t stop there, however.

They verified all the gems that had two or more S3 object versions of the same file — more than 750 in all — and compared the last modification date to the creation date. Only six gems had different date information, and of the six, two had different checksum.

Both gems were manually checked using diff and confirmed to be safe.
It seems safe to say none of the files were maliciously modified, but authors should still ensure that no one who has downloaded and installed that gem would be affected.
The impact on the developer community also appears limited, as gem files modified through this vulnerability would not be installable via the standard “gem install” command, Radcliffe said.

The gem can’t be installed this way, but that doesn’t necessarily mean the file is entirely harmless. One possibility is that the gem could have been swapped with a malware executable that would infect the system after being downloaded.
Trusting community repositories
When it comes to downloading from the Internet, the general practice is to grab the files from official sources.

But there’s been a lot of discussion recently about the trustworthiness of these repositories.
The recent attack against Linux Mint’s website resulted in users being tricked into downloading a modified ISO of Linux Mint 17.3 Cinnamon.

The Node.js community has also had a number of discussions on Reddit and GitHub over the past few days about NPM’s trust model and whether or not the modules from the package manager can be trusted.

At this point, there is no way to verify.
The team at has done a thorough investigation to assure Ruby developers the gems available through the service is safe, and the current policy of using checksums is a good step toward maintaining trust.

But here’s yet another reminder that official sources can be polluted, and it’s up to individual users to balance the risks of obtaining third-party code with the benefits of reusable code.