Sophos Cloud Optix
If you run a website that includes regularly-changing content, like a blog, you may very well use WordPress.
And if your website uses lots of images, at lots of different sizes and resolutions, you may be using a WordPress plugin called TimThumb.
(The name comes from Tim McDaniels, one of the original authors, and thumbnail, the word for a diminutive version of a full-sized image used when space is at a premium.)
A few years ago, as it happens, we wrote about a vulnerability in TimThumb that was discovered and documented by a chap called Mark Maunder.
That vulnerability involved poor handling of untrusted files, so that a crook could persuade your WordPress server to fetch a script from a dodgy website, and save it in a cache directory on your server.
Unfortunately, the cached copy of the crook’s malicious script was not only stored with a predictable name, but also marked as an executable file.
So the crook could then trick your server into running his script, referencing the file on your server using a URL he could guess.
TimThumb adds a WebShot feature
Following this incident, it seems that Mark Maunder ended up becoming a TimThumb developer, getting stuck into a rewrite, and – recently, to judge from the BETA label on the code – adding a feature called WebShot.
Most of TimThumb is used to crop, zoom and resize images automatically, for example to turn big images into thumbnails, or to scale a bunch of differently-sized images so they fit neatly into an image gallery.
WebShot lets you grab remote web pages, render them as they would appear in a WebKit-based browser like Safari, and convert them into screenshots.
Thumbnails, if you like, of the web.
Briefly put, the WebShot feature relies on: running an external command to fetch and render the requested page; grabbing a static image of the video buffer into which it was rendered; and turning it into an image file.
You’re probably thinking, since this article is about an exploit, of all the horrible things that could go wrong if you let a random outsider point your WebShot “pseudobrowser” at a malicious site. (Webshot uses open source tools called CutyCapt, Qt, WebKit and Xvfb to do the heavy lifting.)
What if a crook pushed an exploit into the CutyCapt pseudobrowser running on your server, got control, and took over?
Normally, the crook would need to send you an email linking to a malicious website, hope that you’d be reckless enough to click it, and thereby pwn your PC.
With WebShot, he could automatically instruct your server to “click through” to the malicious site, and thereby pwn your entire WordPress installation, and perhaps more besides!
There’s a lot to worry about, which is probably why the WEBSHOT_ENABLED feature is off by default.
Ironically, however, this latest exploit doesn’t involve CutyCapt, web rendering or image catpure at all.
Command injection vulnerability
Very simply, the WebShot part of TimThumb allowed what’s known as command injection vulnerability.
To tell TimThumb to perform a webshot, you use a special URL in which you embed the name of the web page you want to grab, e.g.
http://blog.example.com/...webshoturl...http://the.url/to/grab
TimThumb then extracts the text http://the.url/to/grab and passes it to the CutyCapt software to fetch.
But TimThumb uses the command shell, usually Bash on Linux/UNIX systems, to run the CutyCapt command, and if you send the Bash shell a text string like this:
$(some command)
then the shell performs what is known as command substitution, replacing that string with the output of running the command some command.
That means that specifying a URL containing a command inside $(...) delimiters would inject that command into the whole process.
So, server software that passes user-supplied text strings to the command shell needs to be really, really careful to filter out dangerous characters, such $(...), specifically to avoid the risk of command injection.
And, until about a day ago, TimThumb did not filter out $(...) correctly, and was therefore vulnerable.
If you had the WEBSHOT_ENABLED option turned on, a crook could trick your server into running commands specificed inside a URL sent to the server, making you vulnerable to Remote Code Execution.
Unfortunately, a hacking crew calling itself CXSecurity that openly prides itself on “Dismissing the conservative manner of publishing information,” openly disclosed this bug to the world two days ago on 2014-06-24.
That turned the bug into a zero-day (a publicly known exploit for which no patch is available) until the TimThumb guys could scramble to fix their code.
What to do?
Fortunately, the TimThumb coders have now included a fix, so if you are a user of TimThumb on WordPress, you can do either or both of these:
- Edit your TimThumb configuration file and make sure that WEBSHOT_ENABLED is set to false.
- Update your TimThumb software file to the latest version
If you have a WordPress site that someone else looks after, feel free to send them a link to this article and ask if they have taken either or both of those precautions.
And, please, if you consider yourself a security researcher and you find an exploitable bug like this, give the authors of the code a fair shot at fixing it before showing everyone else how clever you are.
If you tell the authors and they don’t show any interest in fixing it, then you can consider disclosing the flaw to try to force them to act.
Deliberately turning a bug into a zero day right from the start – especially a bug like this in a tool that the authors look after for free in their spare time – just seems self-servingly mean-spirited to me.
Note. Sophos Naked Security runs on the WordPress platform, hosted by WordPress.com VIP on wordpress.com, which does not use TimThumb.
Image of cartoon man who’s whacked his thumb courtesy of Shutterstock.