TimThumb Image Resizer and Website Security

My friend Alex Denning recently asked me to write some bits about TimThumb for an article he was putting together.

The main purpose of TimThumb was to dynamically resize images on websites, making it easier for web developers to manage their content. Unfortunately it was vulnerable to hacking and many sites were infected because of it.

Shockingly, even today, there are still tens of thousands of sites out there using TimThumb, unknowingly putting themselves at risk.

Fortunately nobody has contacted me about it for a while now so I think use has reduced a lot, but as the article shows there are still a lot of sites using it.

My Memories of TimThumb

Anyway - Alex (or someone in his team) wrote the article which you can see here. The full text I wrote for Alex is below.

Back when we created TimThumb, WordPress didn’t have image thumbnails, so we saw it as a really cool way to enhance website aesthetics. We built it to include in our premium themes that we were about to release, but we didn’t anticipate its popularity. WordPress Theme Shops were still a new concept, so other theme shops like WooThemes bought our theme to use the image resizing script.

At the time, GitHub didn’t exist, so when we open-sourced it, we hosted it on Google Code. The first indication that something was wrong was when my own site was defaced. Someone had changed my footer to link somewhere else. Unsure of the cause, I reverted it and ensured everything was up to date. Fortunately, this was before hackers started introducing backdoors, so it didn’t happen again.

A couple of days later, reports emerged that TimThumb was hacked, and my heart sank. I felt super guilty and spent a lot of time over the next few days trying to make it more secure. Meanwhile, a developer named Mark Maunder was rewriting TimThumb to make it (hopefully) bulletproof, and Matt Mullenweg introduced us. We joined forces to release a more secure TimThumb that was backward-compatible.

Mark went on to found WordFence, a company focused on website security.

The vulnerability arose from a few different factors:

1. I had allowed resizing of external images, which meant files from other websites could be loaded.
2. I enabled data caching for those external files without performing any file type checks to ensure they were images, not code.

Besides feeling really bad about the damage I had caused, I learned a lot from this experience. Since it happened, I have been a lot less trusting of people online and have released a lot less code than I think I might have otherwise. In the projects I have been involved with, I have become very vigilant when it comes to data sanitization and ensuring it is as secure as possible.