[PHP-DEV] JPEG Upload
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. 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-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] JPEG Upload
On Sat, May 5, 2012 at 6:32 PM, Richard Lynch c...@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-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
Re: [PHP-DEV] JPEG Upload
On Sat, May 5, 2012 12:29 pm, Ferenc Kovacs wrote: On Sat, May 5, 2012 at 6:32 PM, Richard Lynch c...@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-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-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] JPEG Upload
On Sat, May 5, 2012 at 7:50 PM, Richard Lynch c...@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 c...@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-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
Re: [PHP-DEV] JPEG Upload
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 On May 5, 2012, at 1:50 PM, Richard Lynch c...@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 c...@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-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-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] JPEG Upload
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] JPEG Upload
On 05/05/12 20:08, Sanford Whiteman wrote: 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] JPEG Upload
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] JPEG Upload
On Sat, May 5, 2012 1:52 pm, Ángel González wrote: I never said it was an iron-clad technique. Only that it would be harder to craft such an image. If your TOU that meta-data gets stripped, so be it. Or find a way to have (some of) your users have some level of trust. To: Tom (?) One doesn't always control one's apache config. Shared hosting, corporate environment with an inexperienced sysadmin, etc. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] JPEG Upload
I dealt with jpegs with injected metadata quite a bit at a previous employer. In the end we ended up confirming the file was a proper image with the filetype functions, then stripping the metadata using some command line tools, and finally using a blacklist for key strings (like ?php) that could show up in the file. paul -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] JPEG Upload
Or find a way to have (some of) your users have some level of trust. Or don't execute anyone's uploads. If you allow people to upload code, make them say it's code (via extension *and* by putting it in an executable area). It is not difficult to predict whether a file will be processed by PHP before worrying about what PHP would do with it. If people really worried as much as they claim to about execution of any old document, robots, htaccess, ds_stores -- and php.inis, for that matter -- would be considered highly dangerous. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
