Does changing an uploaded executable's file extension to .png render it safe?

Question

A colleague of mine has a personal website in which he allows users to upload anything within a certain size,

but before the actual upload he checks to see the file extension:

if ( $type == 'image/gif'){
  $ext = '.gif';
} elseif ( $type == 'image/jpeg'){
  $ext = '.jpg';
} elseif ( $type == 'image/png' ){
  $ext= '.png';
}  else {
  $ext = '.png';  
}

He says to me, that by making all files images no harm can be done to the server.

for example :

  evilscript.evil

would become :

evilscript.png

And be thereby rendered useless. Is there any truth to his claims?

Answer 1

There are basically two main ways an uploaded file can be harmful: by being executed (as a script or binary) or by being run/used in an application and abusing an exploit in it (e.g. an uploaded MP3 which is then opened by a specific player, abusing a known weakness in it).

In other words, it all depends what happens with the file after uploading. If someone is able to upload a Perl script, but the server never executes the uploaded files or even does not have Perl installed, nothing can ever happen. In general: if you make sure that the uploaded file is never run or interpreted you will be safe.

Renaming the files only helps with one thing: on some operating systems, some file extensions may be linked with a specific application. If you rename the file you might prevent that the file will be opened with a linked application. But depending on the system and setup the uploaded files might still get opened with a vulnerable application. To stay in the above example: if any uploaded file gets opened with an MP3 player, even if you rename it to song.png, it would still be able to exploit a weakness in the player (except if the player has its own layer of checking and e.g. does only accept .mp3 files).

The renamed files are not images suddenly, just because of the renaming. On Unix and similar systems, there is even the file command to analyze the type/MIME type of a file.

Bottom line: in my eyes there is only one thing you can do. Be very specific in your setup about what can and will be done with the uploaded files. Any libraries, extensions or applications accepting these files should always be updated to the latest version.

Answer 2

No. Renaming a file doesn't increase security.

He says to me, that by making all files images no harm can be done to the server.

for example evilscript.evil would become evilscript.png

When you rename evilscript.evil to evilscript.png you don't turn it into an image. You just change its name. Generally, a file name isn't relevant. It is just a name given to a block of data, nothing more.

If you can execute an uploaded script, you probably can do it regardless of its name. If you cannot, uploading a malicious script doesn't harm the system, since the script won't be executed anyway.

However, it can prevent a file from being accidentally run. The only protection renaming could provide is the protection from being accidentally launched by Windows explorer (or a shell that similarly uses file extensions). So renaming virus.exe into virus.exe~ actually helps, when you accidentally tap Enter on it.

Unix shells use file formats instead of extensions. As an example, you can save a script as evilscript.png and run it with a Linux shell, providing the file has the "execute" permission. In terms of security, generally it is better to control file permissions instead of file names.

Answer 3

Checking the only extension of an uploaded file is not enough. Eg: check the answer on this question.

A proposal: There is a more reliable way to find out the type of a file. If your friend is running the server on a Unix machine you could use the 'file' command which inspects the contents of the file to determine the format.

Answer 4

There are two isssues, protecting against direct attacks on the server and protecting against attacks on other clients (which in turn can lead to attacks on the server)

First the server, when a client requests a file the server has to decide whether to serve it or execute it somehow. This descision may depend on various factors including.

1. The file extension
2. The directory the file is in
3. Whether the executable bit is set.

I'm not aware of any web servers doing content-inspection on the server side but I can't rule out that one may exist.

Ideally on the server you would not put user-supplied files in a directory where script execution is allowed in the first place, but restricting the file extension is likely a sensible "defense in depth" policy in case a file inadvertantly ends up in the wrong place.

If the server does decide to serve the file it must then decide what mime type to send. Afaict servers usually choose the mime type based on the file extension. The client must then decide what to do with the file. It should base this on the mime type sent by the server but in practice it may instead base it on the file extension or on inspecting the content of the file,

If the browser chooses to treat the file as a type that can involve client side scripting then the domain the file is served from becomes important. If the file is served from your main domain then the script can likely read the cookies you set and use them to impersonate the user.

I belive that a file-extension restriction should be part of the security strategry but it should not be all of it. Storage in directories that forbid script execution, enforcement of contents matching extension and use of a seperate domain name should all be considered as part of the overall defense strategy.

Answer 5

This is safe.

One can always smuggle executable code inside of an image:

• Just upload your PHP code with another extension.
• Put it in metadata, such as EXIF.
• Use specifically colored pixels such that their binary representation is your desired PHP code, which will survive re-encoding (I actually saw this one in real life, exploited using: https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/).

So you should already assume that your file's contents are not safe when they are user-supplied. Even if you re-encode the image, and even if you convert formats, it's still an image so don't bloody execute it. If your web server (such as Apache or Nginx) runs it through the PHP interpreter, then someone will find a way to trigger PHP to do something nasty. By forcing the extension to be one of a few whitelisted extensions, you can tell your web server that it is an image (not executable) and that it should not go through the interpreter.

There are, of course, some related risks to be aware of:

• Your user might put null bytes or other funny things in the filename, which might allow them to choose their extension after all.
• Your user might try to use path traversal if you let them choose the filename, which might allow them to do all sorts of things.
• You might make a mistake in the web server's configuration and everything gets run through the interpreter regardless of the extension (I've seen this before: it's a silent bug, because PHP literally outputs anything it doesn't recognize, so images will look the same before and after PHP interpretation).
• The file might contain an exploit for a specific decoder, for example if you know that the admin might view your image and that they use a browser which has a vulnerable PNG viewer, you could upload an PNG image that exploits that vulnerability.

The first two are easily solved: never let the user choose their filename, or at least whitelist a set of characters that are definitely safe, such as ^[a-zA-Z0-9_-]*$ (alphanumeric, underscore, and hyphen).

The third one can be checked for by putting a file called "test.png" somewhere and putting <?php echo "test1"; in it. When requesting the file via curl, you should see the full code. If you only see "test1", then it's vulnerable.

Finally, the last one is hard to check for and somewhat out of scope. You could use a virus scanner on the server side, but virus scanners only catch a few common cases and will usually not be able to detect all variants of a vulnerability, if they know about the vulnerability in the first place. The user should, ideally, update their system and not run vulnerable software. But if you're in a high-security environment, then you should apply defense in depth and do things like re-encode the image, perhaps only let users view images in a virtual machine, etc. But that's out of scope for this question.

Summary: There are some related attacks that you have not shown to be mitigated, but when only considering the code snippet as posted: that part is safe.