Have you ever worked on a Rails app? That app is vulnerable to a new crop of exploits discovered in the waning days of 2012. Rails 3.2.11 (and 2.3, 3.0, and 3.1 releases) patches those flaws, but until someone runs
gem update or
bundle, an attacker can execute arbitrary code on that machine.
Patrick McKenzie’s excellent blog post inspired this commentary. Read on for a reiteration of his suggestions.
What’s your responsibility to the apps you’ve worked on? Have you moved on to another job, or has your product been transferred to another company? Was it for a client that hasn’t been responsive recently? Does the sysadmin not follow Rails news, or is there no sysadmin at all? If you can’t update the Rails gem yourself, consider a courtesy email to someone responsible:
I have previously worked on XYZ app, and want to let the current maintainer of the app know that a set of new security holes for the underlying technology have been found. It is extremely important that the application be updated immediately, which is an easy task. Leaving the application vulnerable to widespread, automated attacks compromises its server and, indeed, the entire network and all data connected to that server.
Please feel free to contact me for more details. The following links may be helpful:
What’s the danger to yourself? If you still have a Rails server running on your development machine, or the box gathering dust in the corner, it’s vulnerable. As Patrick writes, “No, it does not matter that the Internet can’t connect to your localhost:3000, because your browser can, and your browser will follow the attacker’s instructions to do so.” Update the Rails gem, or terminate the server.
Latest posts by Noah Miller (see all)
- Proofing the App - February 5, 2015
- Adding Dynamically Named Methods to Python Classes - January 29, 2015
- Upsource: New Code Review Tool - August 19, 2014