Timthumb script being compromised – What precautions to take?

2 Views

Read an article about Timthumb script being compromised making WP installations vulnerable. Source here

Taking a look at timthumb.php, There is the following function, which I presume is the culprit.

Read More
function checkExternal ($src) {

    $allowedSites = array(
        'flickr.com',
        'picasa.com',
        'blogger.com',
        'wordpress.com',
        'img.youtube.com',
    );

Since my site is highly customized (therefore is complicated to update timthumb), would it suffice to delete those external domains as all the images are hosted on my server and hence doesn’t require any of the 3rd party domains?

Post Views: 2

Related posts

Leave a Reply

4 comments

  1. Best way: Remove the timthumb script from your server and change your theme so as to not require it in the first place.

    Timthumb isn’t really necessary with newer versions of WordPress. The add_image_size() function can be used to create custom image sizes in the theme. And most older themes I’ve seen still using it were using it to create a “thumbnail” type of functionality, which is now built into WordPress itself.

    The only thing TimThumb really does that WordPress makes hard is the custom cropping, where you can crop images to one side or another instead of doing a middle based crop method. And most themes aren’t using this functionality.

  2. I agree with Otto that is would be much better to use the_post_thumbnail and add_image_size but one other thing that timthumb does is crop images on the fly so on an older site with thousands of images you would have to use
    Regenerate Thumbnails     to re-crop which would be quite a task especially on shared hosting.

    In addition to removing the allowed sites array make sure your server / hosting is configured not to need 777 permissions on the cache folder which I’m sure works with suPHP but does work with DSO chowed to nobody:nobody or www-data:www-data.

  3. The original source for this (link withheld) provided no actual attack vector. Meaning the code you showed above was altered somehow to fetch a remote .php file using $allowedSites.

    How that was accomplished is still a mystery since articles like these don’t really go through the proper advisory’s nor get any peer feedback, and they seem to have no idea how someone wrote a malicious url (like fetchbadphpfile.com) into timthumb.php ( or any other file for that matter).

    Though this is bad coding on the part of timthumb for not validating urls ( or whatever) is still requires a hack either through another security problem or most likely a malicious pre-injected script.

    ps. On a side note timthumb.php did actually have a documented XSS attack vector a few versions ago that went through several security advisories and got practically no attention…