Mark Maunder, the developer who discovered and blogged about the TimThumb vulnerability has himself done a full rewrite of TimThumb and forked it as WordThumb on Google Code. Everything but the original TimThumb image processing has been rewritten, Maunder says.
The full list of all changes have been posted to Maunder’s blog, and it mentions a handful of them. WordThumb is backward compatible with TimThumb’s options, so switching to it from TimThumb is possible. Overall it seems Maunder is attempting to further secure, and generally improve, Ben Gillbank’s TimThumb script.
Will you try out the newly available WordThumb? Do you think those who have used TimThumb in the past, particularly WordPress theme developers, will consider WordThumb now and make the swap?
This is smart. The name “TimThumb” will carry a negative connotation from here on out. It’s best if either the original author(s), or in this case someone else, rewrites, re-brands and re-packages the code. Kudos!
Now this is interesting. Yes, I sure will try it. I’ve been working on a photography theme that uses TimThumb because when the user changes image settings via the options panel it’s easier for them if the new images are auto-regenerated rather than asking them to install a plugin and run it for regeneration of new sizes, compression, etc.. The theme also uses TimThumb’s grayscale filter.
But, as much as I like TimThumb, I’m worried that people will be less likely to buy my theme when I tell them that it uses TimThumb. Like Justin says, the name may be tarnished. This has been a good project that is worth continuing and I’m grateful to those who have worked on it, Mark being the latest with this fork.
Having a PHP file as your img src is far from ideal.
The approach we’ve taken with WP Thumb is to actually create the images on the fly and then serve those, so you get real image paths in your img src whilst still retaining the flexibility of generating images on the fly.
It also integrates directly into all the WordPress functions so you can do things like this.
That will ouput a completely standard img tag:
Check it out on Github https://github.com/humanmade/wpthumb
Hmm, looks like my code example got stripped, see github for examples.
That sounds great. I’ll be taking a look at it later.
+1 (as mentioned in the original timthumb post before)
I agree with Justin, I’m really glad to see this repackaged.
We’ve just transitioned from TimThumb to WordThumb and rolled out an update for all our themes. Really pleased with its performance thus far.
http://churchthemes.net
//Frankie
Looks like I have another update to push…back to timthumb!
//Frankie
Things are moving so fast. Looks like TimThumb and WordThumb have been merged into TimThumb2.0.
http://markmaunder.com/2011/wordthumb-is-now-timthumb-2-0/
The original developer was not MIA at all (he made fixes himself when the exploit was announced) and so working together is very much in the spirit of the GPL and giving back to the community.
Thanks for the heads up Jason.
Yeah, Ben was never really absent at all—personally I think he did a good job of being open and forthcoming about what was going on, in comments etc.—so it was a little odd when the project was forked so quickly.
I’ll have to get another post up, sharing the good news that it’s collaborative now.
Question: We, too, were victimized by this exploit. The odd thing is that it only showed up in one way: Macintoshes were not redirected, nor were PC’s *except* for those clicking on the link provided on the site owner’s Facebook page. The lins on that page, posted automatically when each post is published, are routed through facebook with some sort of hash number I suppose is designed to authenticate the link redirect. I thought the problem might be the URL shortener, but the problem occurred either way. E.g., http://ow.ly/62vj6 (the site has been repaired, of course)
Any idea why just one route resulted in spamsville? I’m suspecting a defect in Internet Explorer, the probable brower used.