Bug 22199 - Safari, like other browsers, actually parses and runs code in favicon.ico
Summary: Safari, like other browsers, actually parses and runs code in favicon.ico
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 312.x
Hardware: All All
: P2 Normal
Assignee: Nobody
Depends on:
Reported: 2008-11-11 22:12 PST by scott
Modified: 2008-11-16 00:12 PST (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description scott 2008-11-11 22:12:28 PST
It took me a while to track down, a clients website was compromised.  The attacker gained access to the site, and stuffed a http redirect in favicon.ico.

This seems to work on all browsers, including Safari Mobile as well.  I am unable to determine a reason why favicon.ico would decode anything by an image format.  It is crafty place to store a redirection, the last place I looked.  

What makes this so interesting, is that a first visit will redirect, but then the icon is cached.  You will end up thinking it was a fluke, as the redirect will not execute again, unless you clear caches of icons.

I suggest that faviicon simply not execute any html or javascript in it.
Comment 1 Mark Rowe (bdash) 2008-11-12 01:41:32 PST
Can you provide an example?  Where does favicon.ico being HTML come into the play?  Your description talks about favicon.ico being a HTTP redirect, which would mean that the *contents* of favicon.ico are never looked at, only the headers.   To what does favicon.ico redirect?

Providing either an example or a clearer description would make this easier to understand.
Comment 2 scott 2008-11-12 15:23:52 PST
Here is the latest exploit I found on a server:
curl http://exploited.sesrver.example.com/favicon.ico
<title>302 Found</title>
<p>The document has moved <a href="">here</a>.</p>
<address>Apache/2.0.63 (Unix) mod_ssl/2.0.63 OpenSSL/0.9.8b mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/ mod_jk/1.2.25 PHP/5.2.5 Server at example.com Port 80</address>

I can not replicate it here, and I do not have physical access to the above server.
Comment 3 Mark Rowe (bdash) 2008-11-12 23:05:48 PST
That is a standard HTTP redirect, which browsers *should* follow when requesting the favicon.  I don't see any evidence that WebKit is doing anything incorrect here.  Feel free to reopen this bug report if you can show that what WebKit is doing is somehow incorrect.
Comment 4 Alexey Proskuryakov 2008-11-12 23:25:38 PST
Are you perhaps saying that a redirect for the icon redirects the main page instead?
Comment 5 scott 2008-11-13 14:51:39 PST
It is hard for me to say much at all, since I do not have access to the exploited machine I noticed this on.  I understand a request for favicon.ico should redirect.  I do not think that is what is happening.

I think if you look at it this way, what if a gif or jpg could have javascript or an http redirect embedded in the binary file?  As a browser rendered the image file, it would then see the malicious code, and follow it's instructions.  I have a strong feeling that is what is happening with the favicon.ico file.
Comment 6 Alexey Proskuryakov 2008-11-13 15:08:06 PST
From the above, it doesn't necessarily follow that the content of favicon is parsed - if may be an HTTP header of the response causing a redirect.

So, it is not clear at all what is happening here, and why it is related to a security breach.
Comment 7 Mark Rowe (bdash) 2008-11-13 15:11:36 PST
Image file formats cannot have redirects inside them.  The header of the response that serves the image can have a HTTP redirect, which the browser should follow.  Can you please provide a URL that demonstrates an actual problem?  There's not much point in speculating about a problem that there is no evidence of.
Comment 8 scott 2008-11-15 22:47:41 PST
I will have to do more research and build a test case, please close for now, and as I have time, I will update this report.  Thank you.