Richard Lynch | 5 May 18:32 2012

[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-xclick&hosted_button_id=FS9NLTNEEKWBE

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Ferenc Kovacs | 5 May 19:29 2012
Picon

Re: [PHP-DEV] JPEG Upload

On Sat, May 5, 2012 at 6:32 PM, Richard Lynch <ceo <at> 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
(Continue reading)

Richard Lynch | 5 May 19:50 2012

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 <ceo <at> 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
(Continue reading)

Ferenc Kovacs | 5 May 19:58 2012
Picon

Re: [PHP-DEV] JPEG Upload

On Sat, May 5, 2012 at 7:50 PM, Richard Lynch <ceo <at> 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 <at> 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.
(Continue reading)

Sanford Whiteman | 5 May 20:08 2012

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

Ángel González | 5 May 20:52 2012
Picon

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

Sanford Whiteman | 6 May 00:16 2012

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

Richard Lynch | 6 May 01:48 2012

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-xclick&hosted_button_id=FS9NLTNEEKWBE

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Paul Reinheimer | 6 May 02:40 2012
Picon

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

Sanford Whiteman | 6 May 06:13 2012

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

Tom Boutell | 5 May 19:59 2012

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" <ceo <at> 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 <at> 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.
>>> 
>>> 
(Continue reading)


Gmane