Re: Image extension issue in mime.php

>>>>>> - 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.

I don't have an opinion about this. Do what you feel is best.

Sincerely,
Fredrik

-------------------------------------------------------------------------
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