Re: Image extension issue in mime.php

On Sun, Aug 24, 2008 at 12:23 AM, Paul Lesniewski <[email protected]> wrote:
>>>>> - IE interprets JavaScript when served within an "image" (that is,
>>>>> something linked from <img src="">. - Apparently (?) it doesn't do this
>>>>> when the file has a regular image extension, it then processes it as an
>>>>> image. A typical Windows way of working I guess.
>>>>>
>>>>
>>>> Hmm.  Can anyone confirm this?  Are there any sample URIs that we can
>>>> see for this?
>>>>
>>>> I tried this in IE6:
>>>>
>>>> <img src='javascript:alert("hello")' />
>>>
>>> The linked image file should contain the JavaScript. E.g.:
>>> <img src='http://example.com/example.html' />
>>> and then example.html contains javascript instead of an image. IE will
>>> allegedly interpret the javascript in the file even though it has no
>>> business doing that as it is an image.
>>
>> I see.  IE interprets any JavaScript loaded in a remote file unless
>> the extension is .png, .gif, etc....?  That's a bit much, now, isn't
>> it?
>
> The only thing I can find is this:
>
> http://ha.ckers.org/blog/20070623/hiding-js-in-valid-images/
>
> but it's limited to the src attribute in a script tag.  I created some
> "hacked" gif files with JavaScript in them and IE 6 (I think this
> might be fixed in IE 7 too) only executes the JavaScript when it's
> included in a script tag.  When you put that into an email, SM
> sanitizes the script tag before the code in question here ever sees
> it.
>
>>  If this is what we are fighting, then the extension list by
>> definition of the way IE works seems like the ONLY way to prevent the
>> problem, that is unless we were to pre-fetch the content and scan it
>> ourselves and judge if the content was really an image file or not.
>
> So, although I'm still not convinced that there should be any
> restriction here at all, I created some code that does just this - it
> keeps the file extension check since that's not resource intensive,
> but if that test fails, it tries to fetch the resource (fopen, fread)
> and then run the content through mime_content_type() to detect the
> content type.  The file is only then blocked if not an image file.
>
> Patch is attached (for STABLE, but should be the same or very similar
> for DEVEL), but again, I'm not sure we need to make any restrictions
> here whatsoever -- ??

Anyone have any feedback on this?  If no one does, what I'm thinking
I'll do is commit this patch, BUT comment it out.  So some code will
be there to use if a vulnerability is found, but for now, the
functionality will be to allow all image src URIs, since I can't find
any evidence that it can be exploited.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: [email protected]
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel