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.
But on should at least you'd have some kind of validation on user input!
--
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
In
most systems you can upload anything with a .jpg extension and the
app will take it, so you can still include the filePeople 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.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
In
most systems you can upload anything with a .jpg extension and
the
app will take it, so you can still include the filePeople 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
In
most systems you can upload anything with a .jpg extension and
the
app will take it, so you can still include the filePeople 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,
seehttp://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
Then one can strip off the exif info with the comments, I believe.
This presupposes that your users don't expect embedded metadata to be
preserved when people redownload the images.
Not only do photo professionals/hobbyists expect you to keep the
metadata, you also should leave it in for reasons of legality. Hosting
a bunch of stripped images can make you look really bad. We only strip
metadata that is known to cause browser display problems (mostly old
IE6/Adobe comment bugs).
Bottom line is you have to make sure PHP never parses the files.
-- S.
This presupposes that your users don't expect embedded metadata to be
preserved when people redownload the images.Not only do photo professionals/hobbyists expect you to keep the
metadata, you also should leave it in for reasons of legality. Hosting
a bunch of stripped images can make you look really bad. We only strip
metadata that is known to cause browser display problems (mostly old
IE6/Adobe comment bugs).Bottom line is you have to make sure PHP never parses the files.
-- S.
Moreover, that still doesn't protect you, as it would be possible to
make a valid image where the payload happened in the image data. I
haven't tried to create such malicious image, but I have found legit
images that tripped bad-image-detection heuristics looking for a 4-byte
magic.
Image contents are "a bunch of random bytes", but 'DROP TABLE Students;'
is binary data, too.
Moreover, that still doesn't protect you, as it would be possible to
make a valid image where the payload happened in the image data...
Agreed. But sanitizing input by silently removing blocks of data your
users rightfully expect to be preserved? That's egregious, even if it
"worked."
(Like many such discussions, I almost can't believe we're having this
one... I mean, executing images is just not normal whether or not you
can "bear the (performance) cost." Who is doing this on purpose?)
-- S.
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 filePeople 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