744993 - arstechnica.com page block as "Reported Attack Site" even though block should have been removed

Status: RESOLVED FIXED

(Toolkit :: Safe Browsing, defect)

Description

[Matt Brubeck (:mbrubeck)]

This has happened to me a few times in the past couple of days.  I don't know if it's a Firefox bug or an issue with the Google safe browsing blacklist, but gcp asked me to enable logging and file a bug if it happened again.

I just opened http://arstechnica.com/ and Firefox displayed a safe browsing error page ("This web page at arstechnica.com has been reported as an attack page and has been blocked based on your security preferences").  However, the Google safe browsing page says "This site is not currently listed as suspicious."

"Of the 609 pages we tested on the site over the past 90 days, 1 page(s) resulted in malicious software being downloaded and installed without user consent. The last time Google visited this site was on 2012-04-12, and the last time suspicious content was found on this site was on 2012-04-10."
http://www.google.com/safebrowsing/diagnostic?site=arstechnica.com

According to gcp on IRC, Firefox should no longer be blocking the site.  Other users on IRC reported the site was not blocked.  When I reload the page or open it in another tab, I get the same error page.  However, it is not blocked when I try to access it from another profile.  When this happened before, I clicked "Ignore this Warning" and was able to view the site, and then I could not reproduce the bug even after restarting the browser.

In the log I see the following error repeated:

no loadgroup notificationCallbacks for http://safebrowsing.clients.google.com/safebrowsing/gethash?client=navclient-auto-ffox&appver=14.0a1&pver=2.2&wrkey=AKEgNivmLRSEfY5GovzpLdrLsceIKkurkQ11PyR-0dVlhlB3I0PFnrliPQhiI8kQlaVWsV38_plt8yRVHoe6aIjuwUnJeTj1Tw==

I also see the following output from the HTTPS Everywhere extension:

> SSL Observatory: Could not get host IP address.

I am using mozilla-central nightly:
Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120412 Firefox/14.0a1

Comment 1

[Gian-Carlo Pascutto [:gcp]]

Can you zip up the /safebrowsing subdir in your profile and attach it to this bug? There is no personal information in there.

Comment 2

[Matt Brubeck (:mbrubeck)]

The file is too large to attach to Bugzilla (~8MB) so you can find it here instead:
http://dl.dropbox.com/u/2128410/safebrowsing.tar.bz2

Comment 3

[Gian-Carlo Pascutto [:gcp]]

While doing some digging, I found 2 phishing links that are warned by Chrome and Beta/Release but not Aurora/Nightly, i.e. so effectively the reverse of this bug:

http://portfoliouk.co.uk/wp-includes/nationalgepartaoinc65GRF53GS6/
http://jonvallis.com/aweber/secure_capitec_secure.co.za/

I think this is a good indication it's a general issue receiving and processing updates, and not related to Completion caching. But I'm checking Matt's data now.

FWIF, all relevant bugs were backed out on inbound until this gets fixed.

Comment 4

[Gian-Carlo Pascutto [:gcp]]

2012-04-20 13:34:02.754534 UTC - -497084672[7fd2e578c690]: Checking /wVwdelSgqW382fjnP1/j/HvOwhZr3n2F/eUPwcPHsg= (757005FF)
2012-04-20 13:34:02.754584 UTC - -497084672[7fd2e578c690]: Probe in test-phish-simple: 757005FF, ready: 1 found 0
2012-04-20 13:34:02.754609 UTC - -497084672[7fd2e578c690]: Probe in goog-phish-shavar: 757005FF, ready: 1 found 0
2012-04-20 13:34:02.754634 UTC - -497084672[7fd2e578c690]: Probe in test-malware-simple: 757005FF, ready: 1 found 0
2012-04-20 13:34:02.754674 UTC - -497084672[7fd2e578c690]: Probe in goog-malware-shavar: 757005FF, ready: 1 found 1
2012-04-20 13:34:02.754721 UTC - -497084672[7fd2e578c690]: Complete in goog-malware-shavar
2012-04-20 13:34:02.754742 UTC - -497084672[7fd2e578c690]: Found a result in goog-malware-shavar: complete. (Age: 86400s)
2012-04-20 13:34:02.754776 UTC - -497084672[7fd2e578c690]: Found 1 results.
2012-04-20 13:34:02.754850 UTC - -497084672[7fd2e578c690]: query took 2ms

So, the entry failed to expire both in Completions and in the Prefix database.

Comment 5

[Shawn Rhode]

I am continuing to see this in Aurora at Ars Technica.  There was an incident with their Ad provider on April 10th.  Within an hour of it being reported, they disabled all ads and worked with their provider to resolve the issue.  Most people are not seeing this problem, however, a few continue to see it and those that do appear to be running Aurora.  My about: string is 'Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120418 Firefox/13.0a2'.  Another user with Aurora on Mac OS X has reported the issue as well.  I don't know their about: string, but might be able to get it.  

Do you want me to enable logging?  I don't see a /safebrowsing directory in my profile, so I am assuming that logging has to be enabled for that to be created?

Shawn

Comment 6

[Gian-Carlo Pascutto [:gcp]]

The /safebrowsing would be in your Local, not Roaming profile. But I have Matt's, so that should be enough to diagnose this eventually.

I landed a huge backout on mozilla-inbound for this, so Nightly should have this fixed over the weekend. If there are no issues with the backout itself, it will go into Aurora next monday, just before the Nightly->Aurora Aurora->Beta migrations.

Comment 7

[Shawn Rhode]

Thanks GCP.  I am applying all the Aurora updates (they seem to happen almost every day) as they come in.  I will see if this behavior continues after next Monday, but it is hard to reproduce it with an reliability.

Comment 8

[Gian-Carlo Pascutto [:gcp]]

Backout landed in beta, and migrated from Nightly to Aurora. The new code is gone everywhere now.

Comment 9

[Gian-Carlo Pascutto [:gcp]]

Bug 673470 landed again, but with a number of additional fixes, some of which will almost certainly fix the underlying issue here, i.e.:
https://hg.mozilla.org/integration/mozilla-inbound/rev/033c251cfddb
https://hg.mozilla.org/integration/mozilla-inbound/rev/df4285386096

Comment 10

[Matt Brubeck (:mbrubeck)]

Fixed by backouts on Fx13 and Fx14, and by changes to the bug 673470 patches that eventually re-landed on Fx17.