402971 - Too many phishing pings in FF2.0.x

Status: RESOLVED FIXED

(Toolkit :: Safe Browsing, defect)

Description

[Garrett Casto]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.6) Gecko/20060201 Firefox/2.0.0.6 (Ubuntu-dapper)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.6) Gecko/20060201 Firefox/2.0.0.6 (Ubuntu-dapper)

Thousands of users are pinging the phishing service significantly more than once every 30 minutes.  Some users (<100) are pinging more than 1000 times an hour.

Reproducible: Always

Comment 1

[Dave Camp (:dcamp)]

Does this state seem to persist at all through restarts?  Like, will the same client stop and then restart pinging too fast?

Comment 2

[Daniel Veditz [:dveditz]]

This is for a list update, not a "check every URL" lookup? That interval is hardcoded, hard to imagine thousands of users hacking listmanager.js buried in our chrome. If it were taken from a pref I could believe a small fraction might tweak it to "be more safe".

Is old bug 115865 relevant here?

Can you tell us anything about the platforms these users are running on from their user agents? Is it all Windows? All Mac? any particular OS version?

Comment 3

[Bill Gianopoulos [:WG9s]]

(In reply to comment #0)
> Thousands of users are pinging the phishing service significantly more than
> once every 30 minutes.  Some users (<100) are pinging more than 1000 times an
> hour.
> 
> Reproducible: Always
> 

Have you verified these are really the same client and not just multiple clients you see as coming form the same IP address due either to natting or http Proxies?

Comment 4

[Garrett Casto]

I'm doing this analysis by looking at server stats, not particular clients, so I don't know if any particular OS/version is causing the problem.  I also don't know if this is a function of restarts, etc.  I have never had an actual client on hand that exhibited this problem.  This analysis is based on cookies, so proxies shouldn't matter.

Comment 5

[Tony Chang (Google)]

We should try to get the user agent strings.  Also, maybe it's a bot or a cookie value that's being set on multiple computers (e.g., a company many have a standard image that includes firefox with a cookie).  Do these users properly respond to back off behavior?

Comment 6

[Garrett Casto]

Certainly it has occurred to me that these aren't actual users.  I was just to make sure that there wasn't a bug that was causing this behavior.  I can try examining user agent strings to see if anything look suspicious.

Comment 7

[Mike Connor [:mconnor]]

Is it not possible to distinguish between full lookups and enhanced mode checks?  We don't have enhanced mode on trunk anymore, but I could easily see 1000 pings an hour if someone's opening a lot of tabs... otherwise I have no idea what could cause this, though the new protocol should support the backoff commands.

Comment 8

[Bill Gianopoulos [:WG9s]]

(In reply to comment #4)
> I'm doing this analysis by looking at server stats, not particular clients, so
> I don't know if any particular OS/version is causing the problem.  I also don't
> know if this is a function of restarts, etc.  I have never had an actual client
> on hand that exhibited this problem.  This analysis is based on cookies, so
> proxies shouldn't matter.
> 
Well, actually could matter.  Depending on how the cookie is set, unless you tell the proxy not to cache the thing that sets the cookie, and unless the proxy actually pays attention, it is possible for every machine behind the proxy to end up with the exact same cookie.  If the cookie setter thing actually runs some kind of JavaScript locally that creates a random number to be used in the cookie, anything that just does a is the cookie set and if not create the cookie on the server side and then send back something to set it, could be being cached on the proxy so everyone after that just gets the same cookie.

Comment 9

[Garrett Casto]

These are all full lookups, not enhanced mode requests.

Cookies are definitely set server side.  However, I'm not in charge of the server that actually sets the cookies.  I'll look into how exactly it's done.

Comment 10

[Daniel Veditz [:dveditz]]

We need to get FF2.0.0.10 out (jar: redirect xss bugs that's affecting Google among others), we can't hold the release to figure this one out. -> 2.0.0.11

Comment 11

[Mike Connor [:mconnor]]

Please renominate if there's more information on this, it seems incredibly unlikely to reproduce easily, given that its thousands out of tens o millions.

At the same time, if we get more info, we'll fix it...

Comment 12

[Garrett Casto]

I agree, this shouldn't hold anything up until we can conclusively figure out if something is wrong.  I'll try and readdress this when I get more time, but unfortunately I'm a little swamped at the moment.

Comment 13

[Bill Gianopoulos [:WG9s]]

Could this be caused by an issue on the client side such as no write access to the url classifier database?

Comment 14

[Daniel Veditz [:dveditz]]

Not enough known to block a security release, but if this gets figured out let us know (assigning to a real person would be a good start).

Comment 15

[Andre Klapper]

Is this still a problem nowadays or can this report be closed as obsolete?

Comment 16

[Dave Camp (:dcamp)]

This hasn't been a problem since 3.0.