438831 - Favicon requests not blocked by urlclassifier

Status: RESOLVED FIXED

(Toolkit :: Safe Browsing, defect)

Description

[nightstalkerz]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1a1pre) Gecko/2008061203 Minefield/3.1a1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1a1pre) Gecko/2008061203 Minefield/3.1a1pre

If an attack site link is clicked on and the Reported Attack Site! window shows up, Firefox should not make a connection to the site either before or after the window shows up.

I had Peer Guardian running and the site was blocked via it.


Reproducible: Always

Steps to Reproduce:
1. Go to the url
2. Check your firewall or other type of network monitor
3.
Actual Results:  
Firefox tries to make a conenction to the site.

Expected Results:  
Firefox should use the urlclassifier3.sqlite to check for the site first.

I'm going to mark this as asecurity bug because I'm not sure what gets sent to the site.

Comment 1

[Johnathan Nightingale [:johnath]]

Hrm - I think I can confirm this.  Visiting the site listed (which is still blocked as of now) gets me the following using livehttpheaders (pasted below).  Two connections:

1) To safebrowsing.clients.google.com as the standard pingback to double check the hash match
2) To the malware site to pull its favicon.

Is favicon service routing around the urlclassifier?  This isn't too terrible since we're not loading anything executable or anything that touches a plugin - but it still exposes attack surface for both our favicon code and the underlying network layers.

-- LiveHTTPHeaders output --

http://safebrowsing.clients.google.com/safebrowsing/gethash?client=Firefox&appver=3.0pre&pver=2.1&wrkey=AKEgNisVT6FYp1xjV6KYQnwh_fbxvyBGUr-Uvkzjcq5iwlmrEmXHmVgWioLmu36c5sk_Iyg0P-zIFBrHH88Dp1Q513-qgS867g==



POST /safebrowsing/gethash?client=Firefox&appver=3.0pre&pver=2.1&wrkey=AKEgNisVT6FYp1xjV6KYQnwh_fbxvyBGUr-Uvkzjcq5iwlmrEmXHmVgWioLmu36c5sk_Iyg0P-zIFBrHH88Dp1Q513-qgS867g== HTTP/1.1

Host: safebrowsing.clients.google.com

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008053011 Minefield/3.0pre

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Content-Length: 25

Content-Type: text/plain

4:20
x.bIÛâK#óe¥^h-¾

HTTP/1.x 200 OK

Content-Type: application/octet-stream

Set-Cookie: PREF=ID=8dffcc95830d16cc:TM=1213276549:LM=1213276549:S=fPW1L7gXx1SGisR9; expires=Sat, 12-Jun-2010 13:15:49 GMT; path=/; domain=.google.com

Date: Thu, 12 Jun 2008 13:15:49 GMT

Server: Hash Suffix Server

Content-Length: 218

----------------------------------------------------------

http://www.loksatta.com/favicon.ico



GET /favicon.ico HTTP/1.1

Host: www.loksatta.com

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008053011 Minefield/3.0pre

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive



HTTP/1.x 404 Not Found

Date: Thu, 12 Jun 2008 11:56:03 GMT

Server: Apache/2.2.3 (Unix) PHP/5.2.0

Content-Length: 209

Connection: close

Content-Type: text/html; charset=iso-8859-1

Comment 2

[nightstalkerz]

The connection to safebrowsing.clients.google.com is understandable but the favicon could contain code which causes a buffer overflow.

Is there any reason why the favicon is downloaded as the Reported Attack Site! page doesn't display it?

Comment 3

[Daniel Veditz [:dveditz]]

malware-checking aside, we always try to load http://<site>/favicon.ico--a de facto standard location--to see if the site has one. Some don't, and the "HTTP/1.x 404 Not Found" response means that this site doesn't have one.

I actually thought we did start the page load before the malware check. We then do the checks while we're waiting for the network response. Normally we hope to get the checks done before we get a response from the site, so we haven't slowed anything down. If we get a hit in the database on the partial match then we have to contact the safebrowsing site so we hold on to any response until we get the all-clear. If the site's OK then we let the response go on into normal processing, if it's not we throw it away.

Our current anti-malware feature only blocks "documents" (which includes frame contents). We don't check or block individual items loaded by a document such as images, though of course if we've blocked a document none of its sub-items would be loaded.

If we're just loading the favicon there's absolutely no harm that can be done. If we've processed it as an image there's potential to trigger a bug -- does this get handed to the image code (assuming an evil site that actually has one, unlike loksatta.com) before we know we're going to block the site and show the custom warning favicon?

Comment 4

[nightstalkerz]

There probably is no harm in loading the favicon.ico but it could be a 10000x10000 px icon which could cause the browser to hang or crash if it does process it.

Comment 6

[Daniel Veditz [:dveditz]]

Not a security exploit, unhiding. If there's an exploit triggerable by a (non-displayed!) favicon then it's easy to slip that image onto any other site.

Anti-malware protection helps, but that can't be the "solution" to attacks because the attackers will always be ahead of the blocking list.

Comment 7

[Johnathan Nightingale [:johnath]]

I believe my patch in bug 453442 should fix this.  Will re-test after that lands.

Comment 8

[Johnathan Nightingale [:johnath]]

After landing the patch for bug 453442 I no longer see any network activity to a blocked malware/phishing site.

Marking this FIXED.

Comment 9

[Johnathan Nightingale [:johnath]]

I guess maybe WORKSFORME is more appropriate, since there wasn't any code change to address this specifically, just a general fix to the way favicon loads are screened? Not sure how much I care... the problem isn't there any more, anyhow.

Comment 10

[Bartłomiej Brzozowiec (BartZilla)]

(In reply to comment #1)
> (...)
> -- LiveHTTPHeaders output --
> 
> http://safebrowsing.clients.google.com/safebrowsing/gethash?client=Firefox&appver=3.0pre&pver=2.1&wrkey=AKEgNisVT6FYp1xjV6KYQnwh_fbxvyBGUr-Uvkzjcq5iwlmrEmXHmVgWioLmu36c5sk_Iyg0P-zIFBrHH88Dp1Q513-qgS867g==
> (...)
> Connection: keep-alive
> 
> Content-Length: 25
> 
> Content-Type: text/plain
> 
> (...)

I guess you have disabled cookies (at least from .google.com). By default, browser sends cookie along with "safebrowsing"-related requests, including /gethash. This has obvious privacy-related consequences. But that's a scope of a (nearly 2 years old) bug 368255, I guess...

> 
> HTTP/1.x 200 OK
> 
> Content-Type: application/octet-stream
> 
> Set-Cookie:
> PREF=ID=8dffcc95830d16cc:TM=1213276549:LM=1213276549:S=fPW1L7gXx1SGisR9;
> expires=Sat, 12-Jun-2010 13:15:49 GMT; path=/; domain=.google.com
> 

It is really "cool" that Google tries to set cookie during this hidden requests, isn't it? But I digress...

(In reply to comment #9)
> I guess maybe WORKSFORME is more appropriate, since there wasn't any code

Yeah, I guess that would be better, because I saw requests not only for favicon, but also for a blocked site itself.
--- ---
T 2008/08/18 02:39:49.283251 1.2.3.4:39835 -> 66.249.91.100:80 [AP]
POST /safebrowsing/gethash?client=navclient-auto-ffox&appver=3.0.1&pver=2.1&wrkey=AK(...)6A== HTT
P/1.1.
Host: safebrowsing.clients.google.com.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1.
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8.
Accept-Language: en-us,en;q=0.5.
Accept-Encoding: gzip,deflate.
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7.
Keep-Alive: 300.
Connection: keep-alive.
Content-Length: 25.
Content-Type: text/plain.
Cookie: PREF=ID=(...).
.
4:20
...i).eV.
......U...

T 2008/08/18 02:39:49.332635 1.2.3.4:21339 -> 64.208.226.73:80 [AP]
GET / HTTP/1.1.
Host: www.ianfette.org.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1.
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8.
Accept-Language: en-us,en;q=0.5.
Accept-Encoding: gzip,deflate.
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7.
Keep-Alive: 300.
Connection: keep-alive.
.

--- ---

You can use http://ianfette.org as a real (ie. resulting in a "gethash" request, unlike hardcoded test sites in mozilla.com domain) test site, I guess (it is harmless, but should be always present in a database, I guess). Note however that after just once visit /gethash result could be cached in a local database, so no other gethash request appear during another visit (at least for some time).

Comment 11

[Bartłomiej Brzozowiec (BartZilla)]

> > http://safebrowsing.clients.google.com/safebrowsing/gethash?client=Firefox&appver=3.0pre&pver=2.1&wrkey=AKEgNisVT6FYp1xjV6KYQnwh_fbxvyBGUr-Uvkzjcq5iwlmrEmXHmVgWioLmu36c5sk_Iyg0P-zIFBrHH88Dp1Q513-qgS867g==

Oh, and when we are at it -- wrkey includes another (apart from cookie, if it is present) unique identifier. But you can't disable it, since it is used during authorization scheme (HMAC-SHA1, to be precise); however, you can completely disable "safebrowsing" (which should be done by default).

Comment 12

[Johnathan Nightingale [:johnath]]

(In reply to comment #10)
> I guess you have disabled cookies (at least from .google.com). By default,
> browser sends cookie along with "safebrowsing"-related requests, including
> /gethash. This has obvious privacy-related consequences. But that's a scope of
> a (nearly 2 years old) bug 368255, I guess...
...
> It is really "cool" that Google tries to set cookie during this hidden
> requests, isn't it? But I digress...

You digress a fair bit actually, Bart.

I have no problem with the idea that you have different opinions on this subject than I do and, conspiracy theories aside, my primary interest is in helping our users so I'm open to discourse that suggests there are better ways. I do have real problems with the way you use any bug in the Phishing Protection component as a soap box though.  It distracts developers, it confuses reporters and, I think most importantly, it makes you seem shrill and rigid, and diminishes the likelihood that people will take your objections seriously.  That feels like a shame to me, because it's obviously a subject you care a lot about, and have thought about extensively; I don't want to lose that voice.  But I will lose it, if the alternative is to have every bug in this component get sidetracked onto a larger policy issue that bugzilla is not meant to solve in the first place.

If you want to change policy, I really think you should take your case to the places where policy is discussed.  Post to mozilla.dev.planning with a considered argument about the relative merits and detriments of the system, and see if you can help others see the feature the way you do.  I'm not at all confident that you'll find much easy support there, many of us believe this is a net-good thing for users or we wouldn't be doing it, but at least the discussion would be happening in the right place.  As it stands right now, not only is your message not coming across the way I think you'd want it to, but I think there's a danger that people will come to write off anyone with privacy concerns as being "another BartZilla crank."  I think that hurts the project, and I would hope you'd agree.