RESOLVED INVALID 22199
Safari, like other browsers, actually parses and runs code in favicon.ico 
https://bugs.webkit.org/show_bug.cgi?id=22199
Summary Safari, like other browsers, actually parses and runs code in favicon.ico
scott
Reported 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.
Attachments
Add attachment proposed patch, testcase, etc.
Mark Rowe (bdash)
Comment 1 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.
scott
Comment 2 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 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>302 Found</title> </head><body> <h1>Found</h1> <p>The document has moved <a href="http://87.248.180.90/in.html?s=sg_err">here</a>.</p> <hr> <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/5.0.2.2635 mod_jk/1.2.25 PHP/5.2.5 Server at example.com Port 80</address> </body></html> I can not replicate it here, and I do not have physical access to the above server.
Mark Rowe (bdash)
Comment 3 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.
Alexey Proskuryakov
Comment 4 2008-11-12 23:25:38 PST
Are you perhaps saying that a redirect for the icon redirects the main page instead?
scott
Comment 5 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.
Alexey Proskuryakov
Comment 6 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.
Mark Rowe (bdash)
Comment 7 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.
scott
Comment 8 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.
Note You need to log in before you can comment on or make changes to this bug.