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 Stil@stilgherrian.com or follow him on Twitter at @stilgherrian
Follow @CSO_Australia and sign up to the CSO Australia newsletter.