From: Paul L. <pa...@sq...> - 2008-08-21 01:30:28
|
All, I was looking at an HTML email today that had an image URI that was an .asp file. SM blocked it, even when I clicked to view unsafe images.... and that's because of the .asp file extension. SM replaces all images in HTML view with a blank image unless they are simple image files with .jpg, .gif, .jpeg, .xjpeg, .jpe, .bmp, .png, or .xbm extensions. In today's world, I think there are probably a lot of images being served dynamically, with URIs that have PHP, JSP, ASP or some other file extension. So, in a lot of cases, these should be allowed and are not necessarily threatening or ill-intentioned. Can someone explain the rationale of keeping the list more restricted? What can a malicious image URI do if we open the list up to such file extensions? Really, if an attacker wanted to do something here, they could easily circumvent this restriction by putting a URI with a "valid" (say .png) extension that was really a php file that is dynamically executed on the target server. So what does SM *GAIN* by keeping this list of known image extensions? (What we *LOSE* is proper display of many valid HTML mails for our users.) My feeling is that this should be addressed by either removing the restriction list completely, adding .asp, .php, .jsp, and any other common types, or putting a new configuration value in the config file for admins who would like to do this themselves. Thoughts please? - Paul |
From: Thijs K. <ki...@sq...> - 2008-08-21 09:58:16
|
On Thu, August 21, 2008 03:30, Paul Lesniewski wrote: > My feeling is that this should be addressed by either removing the > restriction list completely, I would say "yes" to this, but would be curious where the original idea comes from. Isn't that tracable in the commit log? Thijs |
From: Paul L. <pa...@sq...> - 2008-08-22 07:17:11
|
On Thu, Aug 21, 2008 at 2:58 AM, Thijs Kinkhorst <ki...@sq...> wrote: > On Thu, August 21, 2008 03:30, Paul Lesniewski wrote: >> My feeling is that this should be addressed by either removing the >> restriction list completely, > > I would say "yes" to this, but would be curious where the original idea > comes from. Isn't that tracable in the commit log? It's your commit, so maybe you can help. http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail/branches/SM-1_4-STABLE/squirrelmail/functions/mime.php?view=log#rev12370 If this code is meant to stop "request forgeries through included images", I'd like to know more about what this means, since, as I noted, it wouldn't be hard for an attacker to substitute a dynamically executed script for an "image" file on the target server. Or perhaps the file extension code is not specifically what fixed that actual issue and is only a side effect? So if the extension limitation on image files is removed, does this expose SM to some XSS or something that it's not already exposed to now? |
From: Paul L. <pa...@sq...> - 2008-08-22 07:32:00
|
On Fri, Aug 22, 2008 at 12:17 AM, Paul Lesniewski <pa...@sq...> wrote: > On Thu, Aug 21, 2008 at 2:58 AM, Thijs Kinkhorst <ki...@sq...> wrote: >> On Thu, August 21, 2008 03:30, Paul Lesniewski wrote: >>> My feeling is that this should be addressed by either removing the >>> restriction list completely, >> >> I would say "yes" to this, but would be curious where the original idea >> comes from. Isn't that tracable in the commit log? > > It's your commit, so maybe you can help. > > http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail/branches/SM-1_4-STABLE/squirrelmail/functions/mime.php?view=log#rev12370 > > If this code is meant to stop "request forgeries through included > images", I'd like to know more about what this means, since, as I > noted, it wouldn't be hard for an attacker to substitute a dynamically > executed script for an "image" file on the target server. Or perhaps > the file extension code is not specifically what fixed that actual > issue and is only a side effect? > > So if the extension limitation on image files is removed, does this > expose SM to some XSS or something that it's not already exposed to > now? According to: http://www.squirrelmail.org/security/issue/2007-05-09 'Request forgery through images. It was possible to include "images" in HTML mails which were in fact GET requests for the compose.php page sending mail. These images are now properly detected, and the compose form will only send mail through a POST request.' If this is the issue, then the fact that src/compose.php only accepts the "send" variable submission *only* in POSTs, then the image extension restriction is not necessary that I can see. Can someone tell me what I might be missing? Otherwise, I am going to look at removing that restriction list. |
From: Thijs K. <ki...@sq...> - 2008-08-22 07:44:38
|
On Friday 22 August 2008 09:17, Paul Lesniewski wrote: > It's your commit, so maybe you can help. > > http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail/branches/SM-1_4 >-STABLE/squirrelmail/functions/mime.php?view=log#rev12370 > > If this code is meant to stop "request forgeries through included > images", I'd like to know more about what this means, since, as I > noted, it wouldn't be hard for an attacker to substitute a dynamically > executed script for an "image" file on the target server. Or perhaps > the file extension code is not specifically what fixed that actual > issue and is only a side effect? The patch is actually by Marc. He had some discussion about it with Tomas that I could find. As far as I can distill from the mails, but it's a bit of guesswork: - 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. I'm not sure that that is what it's supposed to fix as the mails aren't too clear on that. I also don't use IE so can't easily verify this theory. You could argue that pressing View Unsafe Images leaves you on your own which is sort of true, however, my perception of the function was to prevent remote tracking, and enabling it would not directly open you up to xss. cheers, Thijs |
From: Paul L. <pa...@sq...> - 2008-08-22 08:03:37
|
On Fri, Aug 22, 2008 at 12:44 AM, Thijs Kinkhorst <ki...@sq...> wrote: > On Friday 22 August 2008 09:17, Paul Lesniewski wrote: >> It's your commit, so maybe you can help. >> >> http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail/branches/SM-1_4 >>-STABLE/squirrelmail/functions/mime.php?view=log#rev12370 >> >> If this code is meant to stop "request forgeries through included >> images", I'd like to know more about what this means, since, as I >> noted, it wouldn't be hard for an attacker to substitute a dynamically >> executed script for an "image" file on the target server. Or perhaps >> the file extension code is not specifically what fixed that actual >> issue and is only a side effect? > > The patch is actually by Marc. He had some discussion about it with Tomas that > I could find. As far as I can distill from the mails, but it's a bit of > guesswork: > > - 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")' /> Even when viewing unsafe images (and the file extension list disabled), this is replaced with the "This image has been removed for security reasons" image replacement, presumably because the text "javascript" is found and removed. So, is the actual fix for the javascript issue fixed elsewhere and the image file extension list only intended to avoid showing the "image has been removed" thing when the user does not expect it (because they already clicked to view unsafe images)? Or is there some other URI type that is the real problem here? I'm still not convinced that the list can't be removed, but am hoping anyone with more details or knowledge about the issue can voice their opinion. > I'm not sure that that is what it's supposed to fix as the mails aren't too > clear on that. I also don't use IE so can't easily verify this theory. > > You could argue that pressing View Unsafe Images leaves you on your own which > is sort of true, however, my perception of the function was to prevent remote > tracking, and enabling it would not directly open you up to xss. My thoughts exactly. |
From: Thijs K. <ki...@sq...> - 2008-08-22 09:13:10
|
On Fri, August 22, 2008 10:03, Paul Lesniewski 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. Something like that, all from the top of my head though. Thijs |
From: Paul L. <pa...@sq...> - 2008-08-22 19:33:02
|
On Fri, Aug 22, 2008 at 2:13 AM, Thijs Kinkhorst <ki...@sq...> wrote: > On Fri, August 22, 2008 10:03, Paul Lesniewski 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? 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. There may be a PHP algorithm out there already written to do that, so *maybe* that is possible, but short of that, it looks like we are stuck: have some HTML mails with blanks where images should really be shown or open IE users up to possible attacks via this mechanism. I am going to run a test to try to reproduce the actual IE issue you described, and I am going to look around to see if there is a way we can do a pre-fetch and make a content judgment. Short of any other ideas, though, it looks to me like the only thing we can do is let the admin decide to open themselves up to this, or to build some 2nd level of unsafe image viewing, where the user could click a *second* time to show such images - but that may not be smart, since most users may not understand the risk. Oh, would it be safe to open SM up to any image URI as long as the user agent is not IE? Update - I just tried to use an image URI that loaded a php page that serves this: <script language="JavaScript" type="text/javascript"> alert("HELLO"); </script> And in IE 6 it just gives a broken image (does NOT appear to interpret the JavaScript!), as does FF. Can anyone shed light on the actual vulnerability? |
From: Paul L. <pa...@sq...> - 2008-08-24 07:23:25
Attachments:
check_image_content.diff
|
>>>> - 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 -- ?? |
From: Paul L. <pa...@sq...> - 2008-09-03 00:50:47
|
On Sun, Aug 24, 2008 at 12:23 AM, Paul Lesniewski <pa...@sq...> 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. |
From: Fredrik J. <jer...@sq...> - 2008-09-03 09:00:34
|
>>>>>> - 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 |