Slashdot Mirror
Ask Slashdot: Automated Verification For Uploaded Files?
VernonNemitz writes: There are a lot of ways for hackers to abuse a web site, but it seems to me that one of them is receiving less attention than it deserves. This is the simple uploading of a malware file, that has an innocent file-name extension. I'm looking for a simple file-type verification program that the site could automatically run, on each uploaded file, to test it to see if it is actually the type of file that its file-name extension claims it is. That way, if it ever gets double-clicked, we can be assured it won't hijack the system or worse. At the moment I'm only interested in testing .png files, but I'm sure plenty of web site operators would want to be able to test other file types. A quick Googling indicates the existence of a validator project under the OWASP umbrella, but is it the best choice, and what other choices are there?
this is pretty easy in *nix:
$ file lobotomy.png
lobotomy.png: PNG image data, 298 x 300, 8-bit/color RGB, non-interlaced
$ file jetpack.png
jetpack.png: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, not stripped
This is on the right track, because as others have said, just because it's valid png doesn't mean it's not also valid PHP and Javascript. I just pulled a file like that off a server yesterday.
HOWEVER, -all- of the "download.php" scripts I've ever looked at have at least two of the same three vulnerabilities. Protection from directory transversal is harder than it looks, fopen_url, and memory depletion from failing to disable the output buffer before reading and writing chunks of the file.
A better, safer, higher performance option is to RemoveHandler PHP and RemoveHandler cgi-script in the designated upload directory, which should be the only directory that's writeeable.
A further problem this solves is since the directory is writeable, the designated upload script which checks the files probably is NOT the only mechanism to put files there. Imperfections in other scripts will allow bad guys to upload any file they want, to the world-writeable directory* . Therefore, use httpd.conf to ensure that any scripts in that directory can not run.
* Instead making it -explicitly- world writeable, you can instead use SuExec, which effectively makes the ENTIRE SITE world-writeable. This is extremely stupid.
It's worth noting that this is just a heuristic. A pretty good heuristic for most cases, but a heuristic nonetheless. A file can be a valid-looking PNG and still be malicious. (Heck, it can be valid and still malicious.)
As far as validity is concerned, if you want to go further than file magic checks, you can parse the uploaded file as the expected type. For example, opening it with a library or utility intended for working with those files.
A simple PNG check with image magick:
$ convert png:rot66.png info:-
rot66.png PNG 116x128 116x128+0+0 8-bit sRGB 15.5KB 0.000u 0:00.069
[Return status 0]
$ convert png:rote66.png info:-
convert: Expected 8192 bytes; found 434 bytes `rote2.png' @ warning/png.c/MagickPNGWarningHandler/1831.
convert: Read Exception `rote2.png' @ error/png.c/MagickPNGErrorHandler/1805.
convert: corrupt image `rote2.png' @ error/png.c/ReadPNGImage/4106.
convert: no images defined `info:-' @ error/convert.c/ConvertImageCommand/3187.
[Return status 1]
The file utility thinks rote66.png is a PNG, and it's sorta correct. It has a PNG header at least.
Again, even if you can load a file as a particular type doesn't mean it's not malicious. That rot66.png file in the example above has a chunk of PHP in it. Using another vulnerability to get it included in a PHP script gives some binary junk and the output of phpinfo when it's run. Parsing and resaving can help stem _some_ of this, but it's not without headaches and caveats of it's own.