Message-ID: <BANLkTim2ynuLm2pgYooJ6FsB90QffOeX2g@mail.gmail.com>
Date: Mon, 20 Jun 2011 11:13:50 +0200
From: "HI-TECH ." <isowarez.isowarez.isowarez@...glemail.com>
To: Moritz Naumann <security@...itz-naumann.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Php gif upload thumbnail creation remote
	exploit

Moritz,
I understand your point here. I posted the description of the technique,
because it is a threat actually. You describe that if the appropriate
defensive configuration is in place the technique won't work.
But this can be applied everywhere, it's like saying when you want to defend
against OS level vulnerabilities and local root exploitation you have to install
grsec. Not every admin does that. I see gif uploading with embedded php code
as a real threat and I see it from an attackers perspective. What you do is
looking at the threat from a defense perspective and how to ensure this
kind of attack to fail. In any way looking at real environments this kind
of attack WILL succeed, not everywhere sure but thats thats not what I
was stating
in the advisory.

-kc
2011/6/19 Moritz Naumann <security@...itz-naumann.com>:
> 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/

Powered by blists - more mailing lists