JPEG Upload

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-getimagesize/

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.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

This whole business of bending over backwards to prevent injection of php when apache is misconfigured just encourages apache misconfiguration IMHO. Smart people are protecting you, you don't have to do these things right, don't worry about it!

Sent from my iPhone

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

If the whole thing parses as an image with imagecreatefromjpeg() I
should think that's a bit tougher to create a hack that works.

Then one can strip off the exif info with the comments, I believe.

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.

--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE