Bug 22199

Summary: Safari, like other browsers, actually parses and runs code in favicon.ico
Product: WebKit Reporter: scott
Component: New BugsAssignee: Nobody <webkit-unassigned>
Status: RESOLVED INVALID    
Severity: Normal CC: ap, mrowe
Priority: P2    
Version: 312.x   
Hardware: All   
OS: All   

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