Antivirus Hall Of Shame

[Robert O'Callahan]

I think it might be useful to collect a list of all the crazy ways A/V
software interferes with Firefox. Partly because it's amusing, partly
because it will help tech people appreciate the nonsense we have to put up
with, and partly because it might shame the A/V vendors into being less
crazy.

Recently we discovered
https://bugzilla.mozilla.org/show_bug.cgi?id=733892#c28 : Avast injects a
DLL and then patches JS_EvaluateUCScriptForPrincipalsVersion (and probably
other APIs) to intercept all calls and do something with them --- who knows
what. Sometimes it crashes in its patch code...

I've heard of lots of other issues, like A/V products injecting DLLs that
don't have ASLR enabled, making Firefox less secure. Please contribute!

Rob
--
“You have heard that it was said, ‘Love your neighbor and hate your enemy.’
But I tell you, love your enemies and pray for those who persecute you,
that you may be children of your Father in heaven. ... If you love those
who love you, what reward will you get? Are not even the tax collectors
doing that? And if you greet only your own people, what are you doing more
than others?" [Matthew 5:43-47]

[Justin Lebar]

> I think it might be useful to collect a list of all the crazy ways A/V
> software interferes with Firefox

Perhaps famously,

http://blog.mozilla.org/nnethercote/2012/02/16/mcafee-is-killing-us/
http://blog.mozilla.org/nnethercote/2012/02/17/the-mcafee-site-advisor-add-on-has-an-appalling-memory-leak/

The short version is, McAfee's SiteAdvisor exhibited probably the
worst possible non-malicious leak: All windows were kept alive
forever. McAfee released a "fix" a few weeks later, but this new
version was still exceptionally leaky. The actually fixed version was
released a few days ago. (For those keeping track at home, that's two
months after we first identified the problem.)

This isn't the first problem we've had with McAfee SiteAdvisor:

https://www.google.com/search?q=site:bugzilla.mozilla.org+siteadvisor
https://bugzilla.mozilla.org/buglist.cgi?short_desc=siteadvisor;query_format=advanced;short_desc_type=allwordssubstr

In particular, we blocked an old version for causing problems:

https://bugzilla.mozilla.org/show_bug.cgi?id=637542

> and partly because it might shame the A/V vendors into being less crazy.

In case it's not obvious (it certainly was not to me some months ago),
the PR team is sensitive to this sort of public shaming, and in my
experience, they appreciate being looped in on public statements which
call out bad third-party code. In fact, I imagine they're sensitive
to this thread.

-Justin

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[david bolter]

Does anti spyware count? Using accessibility API just to detect password
fields seems a heavyweight to me.

(Maybe that's our bad)

Cheers,
D

[Nicholas Nethercote]

On Tue, Apr 17, 2012 at 10:28 PM, Robert O'Callahan

<rob...@ocallahan.org> wrote:
> I think it might be useful to collect a list of all the crazy ways A/V
> software interferes with Firefox. Partly because it's amusing, partly
> because it will help tech people appreciate the nonsense we have to put up
> with, and partly because it might shame the A/V vendors into being less
> crazy.
>
> Recently we discovered
> https://bugzilla.mozilla.org/show_bug.cgi?id=733892#c28 : Avast injects a
> DLL and then patches  JS_EvaluateUCScriptForPrincipalsVersion (and probably
> other APIs) to intercept all calls and do something with them --- who knows
> what. Sometimes it crashes in its patch code...

Some other obnoxious things about Avast are listed in
https://bugzilla.mozilla.org/show_bug.cgi?id=735931. For several
reasons, it would only be granted preliminary review (i.e. not full
review) if it were on AMO.

Nick

[Marco Bonardo]

On 17/04/2012 14:28, Robert O'Callahan wrote:
> I think it might be useful to collect a list of all the crazy ways A/V
> software interferes with Firefox. Partly because it's amusing, partly
> because it will help tech people appreciate the nonsense we have to put up
> with, and partly because it might shame the A/V vendors into being less
> crazy.

MS Security Essentials has a quite heavy IO management, to the point it
hangs our UI for seconds each time a download completes and is verified
by it (bug 551427).

It also causes Thunderbird to report an "unable to write to mailbox"
error in some cases, where it keeps temp files busy (bug 720161).

Both of the above issues are not reproducible with Avast.
-m

[Henri Sivonen]

On Tue, Apr 17, 2012 at 5:04 PM, Nicholas Nethercote
<n.neth...@gmail.com> wrote:
> Some other obnoxious things about Avast are listed in
> https://bugzilla.mozilla.org/show_bug.cgi?id=735931.

It's pretty sad that the bug is resolved INVALID. :-(

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

[Nicholas Nethercote]

On Wed, Apr 18, 2012 at 12:23 AM, Henri Sivonen <hsiv...@iki.fi> wrote:
>>
>> Some other obnoxious things about Avast are listed in
>> https://bugzilla.mozilla.org/show_bug.cgi?id=735931.
>
> It's pretty sad that the bug is resolved INVALID. :-(

Block-listing is the only punishment we have for third-party add-ons,
and it's sufficiently harsh that it's only used in extreme cases.
Suggestions for more moderate punishments (e.g.
https://bugzilla.mozilla.org/show_bug.cgi?id=720856) haven't gained
traction.

Well, for this case we could also contact Avast and ask them to play nicer.

NIck

[Robert Kaiser]

Robert O'Callahan schrieb:

> I think it might be useful to collect a list of all the crazy ways A/V
> software interferes with Firefox. Partly because it's amusing, partly
> because it will help tech people appreciate the nonsense we have to put up
> with, and partly because it might shame the A/V vendors into being less
> crazy.

I think we should not use this as just a venting thread, though, IMHO,
we should try to get mechanisms in place how security suites can get
done what they want to do while still making their code compatible
across our binary versions and ideally without causing crashes and such.
I know that this is probably a pretty hard-to-reach goal, but it would
be awesome, esp. for those of our users who are using those security
suites (which is a vast majority of our users).

Robert Kaiser

[Chris Hofmann]

> _______________________________________________

This probably starts with some good/better docs on devmo that tell
plugin vendors and addon the *right* way to do things. Those were
pretty sparse a few years ago, and I don't know if that has improved.

-chofmann

[L. David Baron]

On Tuesday 2012-04-17 23:27 +1000, Justin Lebar wrote:
> This isn't the first problem we've had with McAfee SiteAdvisor:
>
> https://www.google.com/search?q=site:bugzilla.mozilla.org+siteadvisor
> https://bugzilla.mozilla.org/buglist.cgi?short_desc=siteadvisor;query_format=advanced;short_desc_type=allwordssubstr
>
> In particular, we blocked an old version for causing problems:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=637542

Along these lines:
https://bugzilla.mozilla.org/show_bug.cgi?id=521745 wherein they
ignored the thread safety rules in our codebase and
reference-counted main-thread-only objects on other threads, causing
crashes.

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla http://www.mozilla.org/ 𝄂

[Nicholas Nethercote]

On Wed, Apr 18, 2012 at 1:50 AM, Chris Hofmann <chof...@mozilla.com> wrote:
>>
>> I think we should not use this as just a venting thread, though, IMHO, we
>> should try to get mechanisms in place how security suites can get done what
>> they want to do while still making their code compatible across our binary
>> versions and ideally without causing crashes and such.
>> I know that this is probably a pretty hard-to-reach goal, but it would be
>> awesome, esp. for those of our users who are using those security suites
>> (which is a vast majority of our users).
>

> This probably starts with some good/better docs on devmo that tell plugin
> vendors and addon the *right* way to do things.  Those were pretty sparse a
> few years ago, and I don't know if that has improved.

I'd love to know what the correct alternative is to injecting a
DLL and patching JS_EvaluateUCScriptForPrincipalsVersion. Does anyone
even know what this patching could be achieving?

Nick

[Boris Zbarsky]

On 4/17/12 7:39 PM, Nicholas Nethercote wrote:
> I'd love to know what the correct alternative is to injecting a
> DLL and patching JS_EvaluateUCScriptForPrincipalsVersion. Does anyone
> even know what this patching could be achieving?

Well, they could be scanning the script source for some sort of known
malware...

The correct alternative would be for us to expose an API that an
extension can hook into to examine scripts before we run them. We have
a bug open on that.

No matter which way it's done, chances are this is a noticeable
performance drain if each script is actually being analyzed and compared
to some sort of database, sync from inside JS_EvaluateEtc.

-Boris

[Mook]

On 4/17/2012 6:28 AM, david bolter wrote:
> Does anti spyware count? Using accessibility API just to detect password
> fields seems a heavyweight to me.
>
> (Maybe that's our bad)
>
> Cheers,
> D

If I still understand correctly, that is the only ABI-stable way Mozilla
exposes for other processes to see them. (Extensions are ABI-hostile
and API-slushy. Also, in-process.)

--
Mook

[helpcrypto helpcrypto]

I dont know IIRC, but didnt antivirus delete all mail inbox once? (if
a message contains a virus, then all messages must be deleted)

Almost confirmed at: http://kb.mozillazine.org/Antivirus_software
IMHO, that should go on that Hall of Shame.(Really Robert...i love
this thread!!! LOL)

[Erica Jostedt]

+ Kev, Jay, Chris

Thanks for flagging Justin. We are really sensitive to public shaming of partners, especially the ones we work closely with and in this case, they were already working on a fix. This really impacts our relationship w/partners and isn't appropriate.

----- Original Message -----

From: "Justin Lebar" <justin...@gmail.com>
To: rob...@ocallahan.org, p...@mozilla.com
Cc: dev-pl...@lists.mozilla.org
Sent: Tuesday, April 17, 2012 6:27:48 AM
Subject: Re: Antivirus Hall Of Shame

> I think it might be useful to collect a list of all the crazy ways A/V

> software interferes with Firefox

Perhaps famously,

http://blog.mozilla.org/nnethercote/2012/02/16/mcafee-is-killing-us/
http://blog.mozilla.org/nnethercote/2012/02/17/the-mcafee-site-advisor-add-on-has-an-appalling-memory-leak/

The short version is, McAfee's SiteAdvisor exhibited probably the
worst possible non-malicious leak: All windows were kept alive
forever. McAfee released a "fix" a few weeks later, but this new
version was still exceptionally leaky. The actually fixed version was
released a few days ago. (For those keeping track at home, that's two
months after we first identified the problem.)

This isn't the first problem we've had with McAfee SiteAdvisor:

https://www.google.com/search?q=site:bugzilla.mozilla.org+siteadvisor
https://bugzilla.mozilla.org/buglist.cgi?short_desc=siteadvisor;query_format=advanced;short_desc_type=allwordssubstr

In particular, we blocked an old version for causing problems:

https://bugzilla.mozilla.org/show_bug.cgi?id=637542

> and partly because it might shame the A/V vendors into being less crazy.

In case it's not obvious (it certainly was not to me some months ago),
the PR team is sensitive to this sort of public shaming, and in my
experience, they appreciate being looped in on public statements which
call out bad third-party code. In fact, I imagine they're sensitive
to this thread.

-Justin

On Tue, Apr 17, 2012 at 10:28 PM, Robert O'Callahan
<rob...@ocallahan.org> wrote:

> I think it might be useful to collect a list of all the crazy ways A/V
> software interferes with Firefox. Partly because it's amusing, partly
> because it will help tech people appreciate the nonsense we have to put up
> with, and partly because it might shame the A/V vendors into being less
> crazy.
>

> Recently we discovered
> https://bugzilla.mozilla.org/show_bug.cgi?id=733892#c28 : Avast injects a
> DLL and then patches JS_EvaluateUCScriptForPrincipalsVersion (and probably
> other APIs) to intercept all calls and do something with them --- who knows
> what. Sometimes it crashes in its patch code...
>

[Erica Jostedt]

Also plus Fligtar

----- Original Message -----

[Robert O'Callahan]

On Thu, Apr 19, 2012 at 5:46 AM, Erica Jostedt <ejos...@mozilla.com> wrote:

> Thanks for flagging Justin. We are really sensitive to public shaming of
> partners, especially the ones we work closely with and in this case, they
> were already working on a fix. This really impacts our relationship
> w/partners and isn't appropriate.
>

I don't think of these A/V vendors as our "partners" --- they do all kinds
of crazy things to our product that hurt our users and for which we get
blamed, and they rarely tell us what they're doing (as far as I know). We
find out through crash-stats (when they're not suppressing it), or other
tools if we're lucky, and have fun times reverse-engineering their code. If
they're our partners, we're in an abusive relationship.

But I accept this thread was a bad idea and I apologize for my error of
judgement.