// This is the fix for #924:
if($w > 2000 || $h > 2000) return $file;
This will upscale images to a amaximum of 2000x2000 pixels.
Please note that users using the libGD resizing (default) are not too vulnerable because of the used memory check.
Hmm, i don't think that's an good solution:
1. Why the arbitrary 2000x2000 limit? I think it would be better to check the
original dimensions, and prevent any upscaling at all.
2. An attacker will still be able to generate an arbitrary number of thumbnails
on the server. A 2000x2000, 2000x1999, 1999x1999, 1999x1998, etc. sequence
will keep the server busy.
A better solution would be to generate thumbnails only, if the request originated
from the wiki engine. My idea:
1. While parsing, the wiki engine could generate empty placeholder files for
missing thumbnail pictures.
2. feed.php only does the resize if there's a corresponding 0-byte
Well disallowing upscaling could certainly work, though this feature is useful sometimes. Users who would prefer this can change the fix suggested above to the following:
if($w > $info || $h > $info) return $file;
or even nicer:
if($w * $h > $info * $info) return $file;
Your second suggestion wouldn't change anything, because an attacker could simply place a bunch of image syntax tags into a wikipage.
> Your second suggestion wouldn't change anything, because an attacker
> could simply place a bunch of image syntax tags into a wikipage.
Ok, for wiki pages, you're right. But many people are using DokuWiki
as a CMS replacement without any public wiki functionality. For
example, our RoboCup team uses DokuWiki for both the (not editable)
public homepage and the (wiki-)intranet pages in a seperate namespace.
So some checking might improve security against DOS attacks for these