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.
Getting and applying a patch is pretty simple. The list of patches are listed as:
- 2-0-CVE-2009-3009.patch – Patch for 2.0 series
- 2-1-CVE-2009-3009.patch – Patch for 2.1 series
- 2-2-CVE-2009-3009.patch – Patch for 2.2 series
- 2-3-CVE-2009-3009.patch – Patch for 2.3 series
Follow 3 easy steps:
- cd <your_application_root>/vendor/rails
- wget http://weblog.rubyonrails.org/assets/2009/9/4/2-2-CVE-2009-3009.patch
- 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.