I remember seeing an exploit for an image uploading function, which consisted of hiding malicious php code inside a tiff image.
I'm making my own image uploading script, and I assume I'll have to protect myself from this possibility. Except, that I have no idea how it would work. Does anyone know how a php shell hidden inside an image would execute itself? Would it need to be loaded in a certain way?
Thanks.
A brilliant solution just came to my mind.
If you store your images on the separate server/domain/CDN/whatever has no direct access to your code, you have your mission accomplished!
Yes it can. Make a tif file (php-code.tif) with the following code
Then in another script make
include 'php-code.tif'
;See for yourself what happends...
Yes include this would mean the attacker has access to your server OR you uploaded the file yourself as a theme or plugin for a cms... oups!
Now the 2nd part for protecting from such attacks, well I could not find yet a reliable solution, which would work with most CMSs and not involve denying directory listings. Still looking...
Yes it would need to be loaded, probably by a user-supplied variable in an include path, e.g.:
They could also have allowed the user to set the whole filename with a .php extension so all they'd need to do is load it in a browser.
Check that
getimagesize()
doesn't return false, use a random filename, and enforce the file extension. If at all possible don't store the uploaded image in a web-accessible location as it could also contain JS and therefore be an XSS vector.Re-encoding the image can also let you strip nasty metadata and junk at the end which is permitted by several formats (e.g. JPEG)
You can encode web shells into a png image, if you make it right, it will be able to survive the re-encoding as well.
have a look at this
If you only use the GD functions for manipulating the images you should be ok. To be on the safe side, you may convert all incoming images to a specific format that you may consider "safe" ( i like PNG, or JPG, depending if the output intent is display-in-browser or some kind of hi-quality-print). Also, never use the imoage name supplied by the user on your own filesystem. This way it wont be able to put weird data in the filename. To be even safer, you may use the command-line imagemagik conversion utility. This is both faster, and safer.
I don't know about this particular exploit, but usually exploits like this make use of bugs in the software that loads the image. If PHP, or more exactly, the library that loads the TIFF image, will allocate an incorrect amount of memory to hold the image, it might try to load the image in less memory space than is reserved. This is called a buffer overrun.
That also means that a part of the image is loaded in a piece of memory that is not allocated for the image. This part might get executed because it could have actually been reserved for code.
These kinds of problems can arise when there is a bug in the image library. I think a bug like this existed for GIFs in IE 5. The amount of memory that was allocated wasn't determined by the actual file size, but by the file size information in the header of the file. This allowed people to make corrupt gif files, ending with a piece of code that was written in the code segment of the process and could be executed.