New Relic and Rubygems Security

By Posted in New Relic News, Security, Tech Topics, Top Post 30 January 2013

Earlier today, the Ruby community was made aware of a potentially serious breach to Rubygems.org, the external library hosting system used exhaustively in Ruby. The center of the problem was an exploit in a YAML parser that allowed for arbitrary code execution. In this case, a gem was uploaded to Rubygems.org that executed code that copied four configuration files for Rubygems.org itself to a public pasteboard. Beyond the seriousness of a remote code execution exploit, these configuration files contained secure information that could have been used to compromise Rubygems.org’s systems and all hosted gems.

This exploit had the potential for an attacker to add malicious code into any of the gems hosted by Rubygems.org. While the Rubygems team has been diligently auditing their logs and verifying the integrity of the hosted gems, we decided it would be best for our customers if we verified that there is no security threat present in the New Relic RPM gems ourselves.

Verifying New Relic’s Hosted Gems
To verify the gem files that currently exist on Rubygems.org had not been modified from the versions we originally pushed, we verified them against the results of our continuous integration system. Gems that are produced by our continuous integration builds are tested in multiple phases before being released to Rubygems.org. With this information, we were able to confirm that the gem that was packaged for release is the same gem that we tested against, and that it is the same gem actually hosted on Rubygems.org.

We generated the SHA256 hash of the files from our build system and compared them against the SHA hash from the gems hosted on Rubygems.org. In all cases, the SHAs matched and we are confident that the gems hosted on Rubygems.org are the same we released, and therefore safe for you to install.

The hashes for the last seven gem releases are as follows:

4053418460a7d812b955673f6db4f7677d2d64a40caaef3debdc5bc150edec57 newrelic_rpm-3.5.1.14.gem
2c167f0b6459acd0bf09ec94e2c1c0fc869db55da77b235ca435bc0e52dbeea7 newrelic_rpm-3.5.2.17.gem
911782af6128fb8a2b15ca1c39da5b9eccf9fe61b699972d541574dbaf0d8b65 newrelic_rpm-3.5.3.24.gem
292efbba1686cde6c54bbea27a9ead7c5d371ddafe034127ff109e6458201566 newrelic_rpm-3.5.3.25.gem
963973fd222bfcedb8950a930a9e6470366f9a97960fa1e0b35f8161ee5929e4 newrelic_rpm-3.5.4.33.gem
bc9f122833761a727fec629470db727d762167a8129bb9c663d69d4eb13d9241 newrelic_rpm-3.5.4.34.gem
37b3c3653dac30e59060eddd70b7626384e7ed6bed1a6739de90a7e7e90d4b7f newrelic_rpm-3.5.5.38.gem

You can use these hashes to verify against the gems in your cache. Your gem directory can be found by running ““gem environment gemdir““, your gem cache is in the cache directory. If you are on a UNIX like system, you can run the following command to check every version in your cache:

find `gem environment gemdir`/cache -iname 'newrelic_rpm*' | xargs openssl sha256

If you’d like to verify the hash for every gem on your system, the community has assembled a number of scripts to do the heavy lifting. You can use the appropriate script from this gist to check all of your machine’s gems.

Reporting Security Concerns to New Relic
If you discover a security vulnerability in any piece of software, contacting the software maintainers privately should be your first course of action. If you believe you have identified a security vulnerability in any software maintained by New Relic, please email security@newrelic.com to report the issue.

About the author

ckelly@newrelic.com'

Tell us your thoughts Or Send us an internal high five

Talk to @newrelic