Patching Ruby on Rails Refresher

UPDATE: As one comment points out, it is not a good idea to directly patch production unless it was an emergency.  The normal state of patching would be to patch the source and make sure your tests still pass and likely to test on a staging environment.  The process to patch would still be the same as I describe below.

The recent XSS Vulnerability in Ruby on Rails discussed on the Ruby on Rails blog and discovered by Brian Mastenbrook, reminded me about patching my Rails applications which are running vendored.  If not doing this all the time, one can forget how it is done.

All of my production Rails applications keep a copy of Rails in the <application_root>/vendor/rails directory.  This just keeps me in check that I don’t upgrade Rails on a server and possibly break a production application.   The only minor drawback to this approach is when a patch is released, as with this XSS Vulnerability, you have to manually update the Rails installation for each application by hand.  If you don’t do it all the time, one can forget how it’s done.

Patching Rails

Getting and applying a patch is pretty simple.  The list of patches are listed as:

Follow 3 easy steps:

  1. cd <your_application_root>/vendor/rails
  2. wget http://weblog.rubyonrails.org/assets/2009/9/4/2-2-CVE-2009-3009.patch
  3. patch -p1 < 2-2-CVE-2009-3009.patch

You need to know the Rails version you are running vendored before you can determine which patch file to apply.  The simple way for me is to run script/about from <your_application_root>.  This displays the Rails version which you can then choose from the URL links above and replace the URL you need for the #2 wget command.

Depending on the security settings where the application is installed, the wget and patch may need to have a sudo inserted before the command.  I needed to do this my production servers but it would not be needed if patching a local project which would be later committed to source control.

  • Mark

    Patching is good, but you should be patching your source tree and deploying from there (preferably testing the patch in a staging area first), not patching production directly.

  • Mark

    Patching is good, but you should be patching your source tree and deploying from there (preferably testing the patch in a staging area first), not patching production directly.

  • http://www.accidentaltechnologist.com/ Rob Bazinet

    @Mark – Totally agree, I simply patched production as a way to get the apps fixed up now and not something I would normally do. The last part of the post mentions patching at the source.
    The idea here is how to patch, not necessarily where you should apply the patch. I have patched my source too but didn’t deploy that way.

  • http://www.accidentaltechnologist.com Rob Bazinet

    @Mark – Totally agree, I simply patched production as a way to get the apps fixed up now and not something I would normally do. The last part of the post mentions patching at the source.

    The idea here is how to patch, not necessarily where you should apply the patch. I have patched my source too but didn’t deploy that way.