329715 - investigate why some AV's flag us, and prevent it

Status: RESOLVED FIXED

(Toolkit :: Safe Browsing, defect)

Description

[Fritz Schneider]

"I just got thiis very odd alert from my antivirus at home: goog-black-url.sst  was identified as having a signature PHISH.Ebayfraud.AX. The antivirus is AntiVir Free Personal Edition (http://www.free-av.com/ ). "

Comment 1

[Axel Hecht]

The same AV engine just hit me with 
PHISH/Bankfrau.BH.2
in urlclassifier.sqlite-journal.
I guess it's adding the urls to it's phishing specs, just like we do.

Comment 2

[Axel Hecht]

Thinking about it, can we fix this for beta? It'd be really embarrassing to see
"safebrowsing" triggering virus alerts.
Note, that particular AV is really popular in Germany and beta is likely to be the
first release we do with l10n, so dupes of this bug may be #1.

Comment 3

[Mike Connor [:mconnor]]

Tony, any ideas here?

Comment 4

[Tony Chang (Google)]

(In reply to comment #3)
> Tony, any ideas here?

Hmm, we're not currently encrypting the blacklisted URLs, but we can (e.g., we encrypt the licensed urls).  I'll talk with Niels and the rest of the team and see if they have any other suggestions.  The down sides with encrypting is that it's a little slower and it's not as transparent.

Comment 5

[Tony Chang (Google)]

(In reply to comment #1)
> The same AV engine just hit me with 
> PHISH/Bankfrau.BH.2
> in urlclassifier.sqlite-journal.
> I guess it's adding the urls to it's phishing specs, just like we do.

Hmm, so I'm having a hard time reproducing this.  I'm running AntiVir / Linux Version 2.1.7-18 with VDF version: 6.35.0.22 created 12 Jun 2006.

I tried scanning the old style plain text files (*.sst) and the new sqlite files (urlclassifier.sqlite-journal on a full update and urlclassifier.sqlite) using the following command:
  antivir ~/work/avtests/*

Any suggestions (maybe a different OS)?

Comment 6

[Mike Connor [:mconnor]]

pushing out non-critical-path bugs to b2

Comment 7

[Mike Connor [:mconnor]]

Seems to be WFM?  Moving off blocking, renominate if there's a real problem here.

Comment 8

[Tony Chang (Google)]

Note to self, see also:
http://forums.mozillazine.org/viewtopic.php?t=445171
http://img126.imagevenue.com/img.php?image=80091_8945_523lo.jpg

Comment 9

[:Gavin Sharp [email: [e-mail]]]

I've been seeing warnings about viruses in much more frequently lately. I'm using:

AntiVir (Windows)
Virus definition file: 6.35.00.235
Search engine: 7.01.00.21

Unfortunately I'm not able to reproduce consistently. If I see it again, I'll try to save the urlclassifier.sqlite file that triggered it.

Comment 10

[:Gavin Sharp [email: [e-mail]]]

Attachment: urlclassifier.sqlite-journal that triggers the virus warnings

Any time this file is accessed I get the "A virus or unwanted program was found" dialog, using the same versions as in comment 9. I got this file by using a branch build and waiting until I got the alert, then copying the file while the alert was still displayed. Strangely enough, scanning the file directly using the AntiVir UI shows the file as "clean".

Comment 11

[:Gavin Sharp [email: [e-mail]]]

The name that AntiVir gives to that file's "virus" is "PHISH/EbayFraud.CS"

Comment 12

[Bitto]

I can confirm this bug in Windows XP with Avira AntiVir.
I'm getting ebay-fraud warnings on urlclassifier.sql regularly,
and a google search on the file name[1] returns lots of forum entries of people using the beta who are afraid of their data due to this "virus".


[1] http://www.google.de/search?q=urlclassifier.sqlite&ie=utf-8&oe=utf-8&rls=org.mozilla:en-US:unofficial&client=firefox-a 

Comment 13

[Tony Chang (Google)]

I send an email to Avira and they said we should encrypt the urls and "ROT13 would be absolutely sufficient".

Comment 14

[chris hofmann]

I got hit by this on a test system I rounded up that had Avira running on it.  

Pretty confusing, and it took a while for me to track down.  On Wed afternoon I installed the korean and a few other Intl builds, and on Thursday morning at 4:00a Avira pops a dialog that says 

  "C:\path to my profile\urlclassifier.sqlite-journal

Enthalt Signatur der Phish-Datei/Email PHISH/PaypalFruad.U

Then check boxes to:

repair
move to quarantine
rename
access deny
ignore 

It also had a link to search the Avira site for more info on 
PHISH/PaypalFruad.U , but that search returned 
"No Threats were found matching your criteria"

This is going to leave users pretty lost....

Comment 15

[chris hofmann]

move to quarantine is the selected default for users that might hit return....

would that just cause urlclassifier.sqlite-journal to be re-generated? then set up the condition for same warning the next morning when the scan runs again?
or might it do something much worse like hose my profile for anti-phishing stuff? 

Comment 16

[Adam Guthrie]

No, the file would be re-generated and phishing protection would still function properly, I think. See bug 346184 and bug 334174.

Comment 17

[Axel Hecht]

Note that the default action for me is "deny access", if I just saw that dialog correctly.

Which notes that this is a major problem, I just clicked away a warning message of my virus scanner assuming that it's just the shupid antiphishing file. Without thoroughly looking at it or making a conscious decision. That's evil.

Comment 18

[Tony Chang (Google)]

I'll try to make a patch for this today . . .

Comment 19

[Tony Chang (Google)]

Attachment: v1: rot13 keys; switch to a new file

I'm switching to a new filename, which will force the tables to be downloaded again.

Should I go ahead and delete the old file?  Seems like a small number of users would still have it.

Comment 20

[Rob Marshall [tH]]

If you're changing the filename anyway, would it make sense to call it phishing-protection.sqlite or some other name that a user might understand if their AV still flags it?

Comment 21

[Tony Chang (Google)]

Attachment: v2: rot13 key in delete as well

Oops.  V1 changed the select and insert statements, but missed the delete statement.  This picks up that as well.

Comment 22

[Tony Chang (Google)]

on trunk

Comment 23

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 236449 [details] [diff] [review]
v2: rot13 key in delete as well

a=beltzner on behalf of 181drivers

Comment 24

[Tony Chang (Google)]

on branch