Can a php shell be injected into an image? How would this work?

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开发者_JAVA百科 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.

Re encoding the image will not stop someone from uploading a shell. The only sure way to prevent it is to re-encode and scan the image for the presence of php tags.

For an example of a PHP PNG shell that will survive re-encoding

There are some methods to protect yourself from such tricks. Check them out here

Also read this article which explains the attack and ways to tackle it.

The main point stressed in these is the use of basename function of php to defer such attacks.

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

I know there's a way (or was) a way to save a php file as a .gif and have it run the code. In an exploit I saw on the download page the mime type was set as a GIF and the the image was loaded with something to the effect of: require('myimage.gif'); When myimage.gif was actually a PHP file renamed as .gif, including the file would execute the php payload, otherwise the file was just a normal gif. I saw this exploit for an upload script, the hacker also hex edited myimage.gif so that the bytes 47 49 46 38 39 preceded the rest of the file. Those bytes are a GIF header and would trick PHP into thinking the file was a GIF allowing the PHP file to be uploaded bypassing the 'advance' file type checking. This could easily be fixed by building better file checking that made sure the entire file was legit. The easiest way I can think of would be to try to load the image with GD and see if it has an error. I don't think GD would execute the PHP payload but I'm not sure, you would have to test. I assume nearly the same exploit was done or could be done for a tiff or any file type.

In order to make sure your script is not exploited I would take these steps.

1) Set a few file types that you can do Array('.png', '.jpg', '.txt', 'etc') if its not in the array DO NOT allow it. Even if you disallow .php, there's still .php3, .php5 etc that work on some servers.

2) Gaard against myimage.php.gif by saving the uploaded file to a md5 (or a rand name) of the file name (with the exclusion of the file type) so myimage.php.gif would become ef0ca703846cdb7a0131ac2889304a27.gif

3) Check integrity of file, make sure both the header and the rest of the file is legit.

4) Do not use require('myimage.gif'); instead print it's content

Yes it would need to be loaded, probably by a user-supplied variable in an include path, e.g.:

include('templates/' . $_GET['page']);

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)

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.

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

<?php 

  die("TIF file malicious code works");

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...

Unless there's a serious bug in PHP's image handling I don't see how PHP code in an image could ever be interpreted by simply working with it or displaying it.

However there are ways to use images to do Cross-Site-Scripting attacks on users using Internet Explorer

You also need to be careful that users can't upload images that would be used as PHP input. Eg. be being include()d for some reason or by being uploaded with a .php extension.

Apache Multiviews might even lead to images named like image.php.jpg be executed under some circumstances (though I'm not sure about this one).