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

RESOLVED FIXED

Status

()

Toolkit
Safe Browsing
RESOLVED FIXED
5 years ago
3 years ago

People

(Reporter: mbrubeck, Unassigned)

Tracking

({regression})

14 Branch
x86_64
Linux
regression
Points:
---

Firefox Tracking Flags

(firefox13 fixed, firefox14+ fixed)

Details

(Reporter)

Description

5 years ago
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
Can you zip up the /safebrowsing subdir in your profile and attach it to this bug? There is no personal information in there.
(Reporter)

Comment 2

5 years ago
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
Blocks: 673470
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.
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

5 years ago
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
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

5 years ago
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.

Updated

5 years ago
status-firefox13: --- → unaffected
status-firefox14: --- → affected
tracking-firefox14: --- → +
Backout landed in beta, and migrated from Nightly to Aurora. The new code is gone everywhere now.
(Reporter)

Updated

5 years ago
status-firefox13: unaffected → fixed
status-firefox14: affected → fixed
Keywords: regression
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
(Reporter)

Comment 10

5 years ago
Fixed by backouts on Fx13 and Fx14, and by changes to the bug 673470 patches that eventually re-landed on Fx17.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(Assignee)

Updated

3 years ago
Component: Phishing Protection → Phishing Protection
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.