Nasty Ruby on Rails vulnerabilities highlight small websites' risk to us all

Tech-illiterate worry-when-it-happens managers and selfish "write-only programmers" combine to kill web application security.

The revelation of serious long-term vulnerabilities in the popular Ruby on Rails web programming framework is just one of three events in the last 72 hours that have convinced me that improvement in web application security is impossible -- unless both developers and business managers seriously lift their game.

The Rails vulnerabilities are both bad, as the announcement accompanying the fixed software made more than clear. "Extremely critical security fixes so please update IMMEDIATELY," it said. Check CVE-2013-0155 and CVE-2013-0156 for the gory details.

It's the second hole that should have us all shitting bricks.

"It allows for full remote code execution against any Ruby on Rails application that has the XML parser enabled, which is [the] case by default," wrote Sourcefire's Adam O'Donnell.

"More plainly, it means that anyone can run a unix command with the same privileges as the Ruby on Rails application under the default install, even if you are not processing XML as part of the code you created."

O'Donnell is pretty blunt about what should be happening next.

"If you are running Rails code, stop what you are doing and upgrade your Rails environment right now. If you are managing people who are writing Rails code, get them to upgrade their environment immediately. If you are a web hoster that has a significant number of people running Rails code, contact your customers and get them to upgrade. Order lunch in. Don't go home. Stop reading this and fix the problem."

O'Donnell is right, at least about that part. It looks to me like anyone can walk up to your Rails application right now and do whatever the heck they want. Immediate action is required.

However I'll take his warnings about an imminent global worm attack on the 2013-equivalent scale of the Code Red outbreak of 2001 with a grain of salt. At least until I've thought through the mathematics.

Thing is, I strongly suspect that in the majority of businesses running Rails applications, immediate action won't take place. No action will take place. Because it never does. And it's the other two, less-public, events than have convinced me of this.

First, business managers are a problem.

A client emailed me to ask for a refresher in operating their website, which we'd built to their designer's specification in WordPress.

Now the last work we'd done on this site was in mid-2009. Then at the end of 2010 the client declined our offer to continue maintaining their WordPress installation for a fixed annual fee.

Sure enough, the site is still running WordPress version 3.0.4 rather than the current 3.5, making it trivial to hack.

(That it hasn't been hacked is presumably down to a combination of good luck and running Trustwave's mod_security plug-in for the Apache web server, which provides a simple but seemingly-effective web application firewall.)

Of course WordPress isn't Ruby on Rails, and none of us need the tedious grief of yet another zealot-infested whinge about the relative security of the fashionable web application frameworks and content management systems. But they do have one key element in common. They're both used by developers, often self-taught, who build straightforward, low-cost websites for technically-illiterate customers.

Customers who think that because they're not making changes to the site that they don't have to think about it.

As I explained to another client this week, that assumes that the entire rest of the universe stops changing too, which it doesn't.

"There will always be the need to maintain any existing code in the face of changes to WordPress and, far less frequently, the programming language it's written in, the database it talks to, and any underlying system tools, as well as discovering any 'new' bugs that for whatever reason weren't discovered previously -- usually because the precise circumstances that trigger the bug haven't been encountered before, or weren't even envisaged in the first place. This is normal," said.

"I'm not foreseeing any particular need for work or changes [to your website]. I just want to crush without mercy every ounce of hope you might have in the impossible dreamworld of 'software that doesn't require maintenance'."

This client indicated that their hope had been suitably crushed. Good. But in my experience the majority of business managers glaze over at the very first mention of anything remotely technical, sputter a tween-like "Whatever", and move on.

Business managers need to lift their game. They need to pay attention to infosec-related business risks as much as they do to cashflows, fire insurance and the locks on their doors. Their board members need to hammer them about it.

Second, developers are a problem.

Yet another client website had some functionality break during a routine WordPress update some months back. The original developer of a custom plug-in is no longer available, so we asked the client's new dev firm to take a look.

What I discovered this week was that instead of quoting for their WordPress developer to fix the broken plug-in, the new firm is going to build a whole new website using completely different tools. Eventually.

Now in this particular case there happen to be valid reasons for doing that. This site is one of a set that are about to be rebuilt to a common framework. But it does highlight one seldom-discussed truth.

Developers like writing new code, hate fixing their old code, and loathe working with any code they didn't write themselves.

I feel their pain. I spent half a day this week reverse-engineering someone else's code and it ain't fun. But sometimes it's what needs to be done to provide the best value to the client.

Programming is not a write-only job.

But the global shortage of developers in Dotcom Boom 2.0 and the outlandish salaries that go with it seem to have blinded many developers to the fact that they're in a service industry. May the bubble soon burst, I say!

Now combine these two problems.

Developers soon give up trying to convince business managers to pay for work they don't really want to do in the first place. Assuming, that is, they're still in touch with clients from years ago, and that the clients even know that they have websites built in this thing called Ruby on Rails.

Now that I think about, O'Donnell is probably right about the worms.

Contact Stilgherrian at or follow him on Twitter at @stilgherrian

Follow @CSO_Australia and sign up to the CSO Australia newsletter.

Join the CSO newsletter!

Error: Please check your email address.

Tags ruby on railssecurity vulnerability

Show Comments

Featured Whitepapers

Editor's Recommendations

Solution Centres

Stories by Stilgherrian

Latest Videos

  • 150x50

    CSO Webinar: Will your data protection strategy be enough when disaster strikes?

    Speakers: - Paul O’Connor, Engagement leader - Performance Audit Group, Victorian Auditor-General’s Office (VAGO) - Nigel Phair, Managing Director, Centre for Internet Safety - Joshua Stenhouse, Technical Evangelist, Zerto - Anthony Caruana, CSO MC & Moderator

    Play Video

  • 150x50

    CSO Webinar: The Human Factor - Your people are your biggest security weakness

    ​Speakers: David Lacey, Researcher and former CISO Royal Mail David Turner - Global Risk Management Expert Mark Guntrip - Group Manager, Email Protection, Proofpoint

    Play Video

  • 150x50

    CSO Webinar: Current ransomware defences are failing – but machine learning can drive a more proactive solution

    Speakers • Ty Miller, Director, Threat Intelligence • Mark Gregory, Leader, Network Engineering Research Group, RMIT • Jeff Lanza, Retired FBI Agent (USA) • Andy Solterbeck, VP Asia Pacific, Cylance • David Braue, CSO MC/Moderator What to expect: ​Hear from industry experts on the local and global ransomware threat landscape. Explore a new approach to dealing with ransomware using machine-learning techniques and by thinking about the problem in a fundamentally different way. Apply techniques for gathering insight into ransomware behaviour and find out what elements must go into a truly effective ransomware defence. Get a first-hand look at how ransomware actually works in practice, and how machine-learning techniques can pick up on its activities long before your employees do.

    Play Video

  • 150x50

    CSO Webinar: Get real about metadata to avoid a false sense of security

    Speakers: • Anthony Caruana – CSO MC and moderator • Ian Farquhar, Worldwide Virtual Security Team Lead, Gigamon • John Lindsay, Former CTO, iiNet • Skeeve Stevens, Futurist, Future Sumo • David Vaile - Vice chair of APF, Co-Convenor of the Cyberspace Law And Policy Community, UNSW Law Faculty This webinar covers: - A 101 on metadata - what it is and how to use it - Insight into a typical attack, what happens and what we would find when looking into the metadata - How to collect metadata, use this to detect attacks and get greater insight into how you can use this to protect your organisation - Learn how much raw data and metadata to retain and how long for - Get a reality check on how you're using your metadata and if this is enough to secure your organisation

    Play Video

  • 150x50

    CSO Webinar: How banking trojans work and how you can stop them

    CSO Webinar: How banking trojans work and how you can stop them Featuring: • John Baird, Director of Global Technology Production, Deutsche Bank • Samantha Macleod, GM Cyber Security, ME Bank • Sherrod DeGrippo, Director of Emerging Threats, Proofpoint (USA)

    Play Video

More videos

Blog Posts

Market Place