Is there a trade-off between convenience and security when using Ruby Gems in your web app?

Ruby is a dynamic, multi-paradigm, object oriented programming language created in the 1990’s by Yukihiro Matsumoto. Its elegant syntax and flexibility has made it one of the most appealing programming languages for development and as a result, today, Ruby enjoys a vast community of developers. Since its creation, Ruby and its continuously expanding community have been making a great impact on the web development industry.

One of the core advantages of Ruby is its vast collection of programs and libraries, offering various solutions and functionalities, called Ruby Gems.

Gems are standard format, self-contained, reusable programs and libraries, distributed by the Ruby community through a package manager called RubyGems, hosted at rubigems.org. Ruby Gems allow programmers to easily share their code and add functionality to their applications in just few lines of code.

According to the official website of Ruby there are 140,920 ruby gems which are downloaded over 19 billion times.

No other language enjoys a better system for sharing programing solutions between developers. As a result, every Ruby developer today is using someone else’s code in their application.

But what about security risk? Does the convenience of quickly adding Gems to your application come for a price?

By using someone else’s code, you lose control over the security aspects of your application. No matter how careful you are and how perfect your code is, using someone else’s code could bring vulnerabilities to your app.

For example, Figure 1 and Figure 2 display the statistical information for vulnerabilities in Ruby on Rails Gem by year and type respectively, published by cvedetails.com. The ways of attack are always different which shows improvements in the security but every year new problems occur.

Ruby Gems are prone to the same security vulnerabilities any application could be and it would be highly inefficient if you must inspect all their code, and the code of all their dependencies, for any vulnerabilities.

As evident by the publications of some Ruby developers like Rob Race who discusses the most used Gems in his application development process, an average Ruby application could use more than twenty Gems, and each Gem used in it could have number of dependencies.

The discovery of a vulnerability has the potential to affect large number of systems because of the fact that gem packages are widely used among a multitude of development projects.

Here are some examples showing the potential risks and the potential impact from Ruby Gems vulnerability exploits. The examples below discuss reported vulnerabilities in the Ruby Rails Gem.

Two XSS vulnerabilities were discovered in 2017 in the Ruby Rails Gem by Zachary Sanchez of Cisco ASIG, reported in talosintelligence.com. An attacker exploiting the vulnerability could execute arbitrary JavaScript code in the user’s browser. The attack could be used for phishing the user or stealing the user’s cookies.

A serious vulnerability in Rails Gem was reported by Heroku in 2013. Its exploit would affect all systems running Rails and would allow an attacker to gain access to their applications. A patch was quickly released to solve the problem.

Gems could also be modified by an attacker and used as a vehicle to carry an attack to your application and the underlying system.

For example, an unsafe object deserialization vulnerability in RubyGems package manager was reported at RubyGems.org on October 2017. The vulnerability could be used to inject an arbitrary Ruby object in any Gem. The vulnerability was promptly fixed and all Gems in the repository were audited. The vulnerability was presented in the system as early as 2012 and remained unnoticed until 2017.

Your application could also be attacked by altering the source of the Gems used in it.

A major security vulnerability in the Gem Bundler was reported in 2016, which allowed an attacker to inject arbitrary code into your application through the declared source of a Gem in your Gemfile. The hack exploits the ability of the Gemfile to declare different sources for different Gems.

Gems security is actively discussed within the Ruby community. Vulnerabilities in the Ruby Gems are continuously discovered and reported.

Good sources to keep yourself informed about security bugs in publicly released software packages are the Common Vulnerabilities and Exposures (CVE) databases.

The online Git repository GitHub has launched a new feature in 2017 which alerts developers about vulnerabilities in their project dependencies based on information from the CVE databases. The security alert system notifies all affected repositories for the reported vulnerability.

RubyGems.org has a guide about security practices when building and installing Gems. RubyGems package manager can cryptographically sign gems and package them together with the signing data, which then can be verified prior installation. This can prevent developers from installing maliciously modified Gems in their applications. Unfortunately, according to the website, the mentioned security method is not widely implemented.

Another Ruby community effort to cope with the security problems is the Ruby Advisory Database at GitHub.com, where everyone can report newly discovered vulnerabilities in any Ruby package. The database lists all known vulnerable Ruby Gems and the developer can check their own applications against it by using the bundler-audit Gem.

Ruby Gems are very convenient and widely used by Ruby developers. They give you an edge as a developer and let you quickly produce sophisticated applications. However, there is a clear trade-off between convenience and security when using someone else’s code in your app and it is your responsibility as a developer, or a team of developers, to use all the available tools and resources to mitigate that risk.