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 RubyGems.org 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 RubyGems.org 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 RubyGems.org 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 RubyGems.org," 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.
Sign up for CIO Asia eNewsletters.