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
