Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60477
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <58e8965ff524a3ff98ba3cbb5028ddba.squirrel@www.l-i-e.com>
References: <b7af37b0e8d38a500944f542b7ff234e.squirrel@www.l-i-e.com>
	<CAH-PCH6oBe1uVtWoLWyr3+FvEVBxaWZNK+JWtRLx6U0FzSgXDQ@mail.gmail.com>
	<58e8965ff524a3ff98ba3cbb5028ddba.squirrel@www.l-i-e.com>
Date: Sat, 5 May 2012 19:58:10 +0200
Message-ID: <CAH-PCH7O=ZNJrxpybSULOdGLHi-nnNk6e9tdW9ko7RPDygpHVA@mail.gmail.com>
To: Richard Lynch <ceo@l-i-e.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=20cf3079b7fcae153004bf4dc7b0
Subject: Re: [PHP-DEV] JPEG Upload
From: tyra3l@gmail.com (Ferenc Kovacs)

--20cf3079b7fcae153004bf4dc7b0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, May 5, 2012 at 7:50 PM, Richard Lynch <ceo@l-i-e.com> wrote:

> On Sat, May 5, 2012 12:29 pm, Ferenc Kovacs wrote:
> > On Sat, May 5, 2012 at 6:32 PM, Richard Lynch <ceo@l-i-e.com> wrote:
> >
> >> On Tue, April 10, 2012 1:13 pm, John Crenshaw wrote:
> >> >In
> >> > most systems you can upload *anything* with a .jpg extension and
> >> the
> >> > app will take it, so you can still include the file
> >>
> >> People don't use imagecreatefromjpeg() to be sure it isn't some ware
> >> or executable or PHP script disguised as a JPEG?!
> >>
> >> That's just crazy.
> >>
> >> And inexcusable in a framework.
> >>
> >> Somebody might be able to craft a "JPEG" that validates and still
> >> manages to somehow parse some PHP in the middle... Probably using
> >> JPEG
> >> comments so it's easier.
> >>
> >>
> > yeah, and injecting php code through the jpeg comments isn't new also,
> > see
> >
> http://ha.ckers.org/blog/20070604/passing-malicious-php-through-getimages=
ize/
> > but
> > I bet I could find even older posts discussing the topic.
> > so imo the correct remedy for this situation is to prevent your
> > uploaded
> > files to be executed at the first place, instead of trying to write an
> > error-prone method to detect malicious content inside your uploaded
> > media
> > files.
>
> getImageSize is not better than file Info...
>

I didn't talked about at all.


>
> If the whole thing parses as an image with imagecreatefromjpeg() I
> should think that's a bit tougher to create a hack that works.
>

maybe, but would you bet your site's security on it?


>
> Then one can strip off the exif info with the comments, I believe.
>

yeah, you just have to totally understand all of your supported media
formats just to make sure that there is no other way to inject malicious
php code.


>
> And, yes, ideally one would keep images in a totally separate
> directory not even in the webtree... Which I do, but some folks can
> bear the cost of passing the image "through" PHP.
>

yeah, for bigger sites, you would already serve the static assets through
some other http server (something lightweight more suited for serving
static files, like nginx, cherokee, lighty, etc.) on a separate domain, on
a separate box.
even if you serve those on the same vhost, you could still do engine off (
http://www.php.net/manual/en/apache.configuration.php#ini.engine) for that
directory where you keep your uploaded files, which would prevent the
direct execution of those files.
one could still execute those malicious files if you have a Local File
Inclusion vulnerability but if you do, that's game over for most
cases already.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--20cf3079b7fcae153004bf4dc7b0--