full-disclosure - Re: Php gif upload thumbnail creation remote exploit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4DFDF076.7030505@moritz-naumann.com>
Date: Sun, 19 Jun 2011 14:49:58 +0200
From: Moritz Naumann <security@...itz-naumann.com>
To: isowarez.isowarez.isowarez@...glemail.com
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Php gif upload thumbnail creation remote
	exploit

On 19.06.2011 13:35 HI-TECH . wrote:
> A good and working example for this technique is the "EQdkp-Plus" PHP Software,
> the URL http://<hostname>/dkp/plugins/mediacenter/upload.php
> allows to upload image files. There are two checks made by the software:
> * Extensions check, where they forget to check for the php3 extension,
> which might be parsed by the webserver as php code.
> * Check if the upload is actually an image.

Either you or the developer of this software or both of you are missing
the point here: in terms of server side security it does not matter
whether or not PHP code is stripped off an image file by the time it is
converted. In fact, you can always legitimately have comments and other
meta data in image and other media files which are often stored as
unmodified plain text and this could also include PHP code.

What does matter is that this application, its documentation, the
installation you tested against or a mixture of these allow for
executing anything within the "thumbs_b" (and possibly other directories
which contain file uploads) as PHP code in the first place.

Any properly configured webserver which supports CGI or SAPI disallows
any dynamic processing of stored content by default, and only allows for
it in given whitelisted locations. In case of mod_php, this means that
the AddType association should only be in place for a given set of
directories and/or files which are actually meant to contain executable
PHP code. mod_php also offers the PHPEngine bit for this purpose (but
this is flawed by design, since you must not make the process you want
to secure against take the decision whether or not it will run).

Defaulting to no PHP support may not be an option for shared hosting,
but then users and applications - by providing proper documentation and
default setups/webserver configuration snippets - can still choose to
secure the environment they operate in by using a blacklisting or - much
better - a whitelisting approach.

All of this has been said and written many times before - I'm just
summing it up once again since this is still a common mistake which both
software developers and server administrators / shared hosting users
keep repeating on a daily basis. Since shared hosting users are usually
allowed to have no clue of what they are doing, the responsibility is
very much in the domain of server administrators and application
developers to provide secure environments and defaults, as well as good
and easily accessible documentation.

Moritz

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/