This bug was filed from the Socorro interface and is report bp-86a4ec30-4d54-4372-bc4f-3ce6f2131009. ============================================================= This is rising on crash lists for Fx24 and Fx25. Some of the signatures are startup crashes. No reports currently on Fx26 or Fx27. bitguard appears to be installed with some other toolbar addons.

Added a couple more signatures related to bitguard.dll. Combined Ranking: * Release: #8 (5801 crashes) * Beta: #58 (550 crashes) * Aurora: N/A * Nightly: N/A Some of the signatures have reports going back really far (bitguard.dll@0x16cce7 has reports against Fx 3.6) so maybe a toolbar update was pushed recently which caused this to spike.

The company which owns the BitGuard software is called MediaTechSoft, but I can't see anywhere to download their software: http://www.mediatechsoft.com/index.html I've tried installing several peices of software and add-ons seemingly related to bitguard.dll but have not found a way to get this dll on my system as of yet. After some digging it appears this dll is known to be malware, we should probably just try to block it, in fact nearly all search results for bitguard return malware removal and warning pages. Here are two examples: * http://www.411-spyware.com/file-bitguard-dll * http://www.freefixer.com/library/file/bitguard.dll-100058/

Nominating for tracking just in case.

Discussing both bug 923583 and which versions of this DLL are affected in crash-kill.

Here's a few correlations from yesterday on this: RtlAllocateHeap | bitguard.dll@0x16cf7c|EXCEPTION_STACK_OVERFLOW (761 crashes) 100% (760/761) vs. 11% (11280/99858) BitGuard.dll 0% (0/761) vs. 1% (764/99858) 2.6.1673.238 100% (760/761) vs. 11% (10516/99858) 2.6.1694.246 RtlpLowFragHeapAllocFromContext | bitguard.dll@0x16cf7c|EXCEPTION_STACK_OVERFLOW (96 crashes) 100% (96/96) vs. 11% (11280/99858) BitGuard.dll 0% (0/96) vs. 1% (764/99858) 2.6.1673.238 100% (96/96) vs. 11% (10516/99858) 2.6.1694.246 _SEH_prolog4|EXCEPTION_STACK_OVERFLOW (1129 crashes) 100% (1127/1129) vs. 11% (11280/99858) BitGuard.dll 0% (0/1129) vs. 1% (764/99858) 2.6.1673.238 100% (1127/1129) vs. 11% (10516/99858) 2.6.1694.246 ntdll.dll@0x2defe|EXCEPTION_STACK_OVERFLOW (845 crashes) 100% (845/845) vs. 11% (11280/99858) BitGuard.dll 0% (0/845) vs. 1% (764/99858) 2.6.1673.238 100% (845/845) vs. 11% (10516/99858) 2.6.1694.246

We can block a DLL below a certain version, but we can't block a specific range. So I can block bitguard.dll all the way up to 2.6.1694.246 but I can't block 1694.246 while still allowing 1673.238.

Here's the DLL blocklist patch if we want to take it.

Comment on attachment 816736 [details] [diff] [review] bug925459-bitguard I think the topcrash designation on both FF24 and FF25 warrants trying this out. Let's go for it.

https://hg.mozilla.org/releases/mozilla-aurora/rev/e332f0f11ce7 https://hg.mozilla.org/releases/mozilla-beta/rev/757597594469

-central checkin still needed.

Although QA was not able to reproduce this crash originally I'm marking this verifyme and we'll evaluate based on crashstats in a few days.

[@ bitguard.dll@0x16d047] is not fixed by this on Fx25 on builds for 20131017174213

We should back this out from m-b in that case. RyanVM is out, can you help bsmedberg?

Only one signature continues to show up in our topcrash reports and that is bitguard.dll@0x16d047: * Release: #190 * Beta: #22 * Aurora: #145 * Nightly: N/A It looks like this is dropping off so updating accordingly. I will continue to watch this as we approach release though.

Benjamin mentioned in the meeting that his data shows this is no better or no worse on the latest Beta. Alex is currently leaning toward a backout of the blocklist since it doesn't appear to be working. Sorry for the noise.

backout: https://hg.mozilla.org/releases/mozilla-beta/rev/6b2f93d57181 I'm going to leave this in aurora for right now because it's possible that bug 927944 may actually make the block effective, and I'm planning on asking for uplift there.

Current Rank: * Firefox 24: #10 * Firefox 25: #45 * Firefox 26: #228 * Firefox 27: N/A This is still a topcrash but for Firefox 24 only. Since this is WONTFIX for Firefox 24 I'm removing the topcrash keyword.

Seems like this is wontfix for Fx25?

And now we have e.g. this one as a 24 topcrash: https://crash-stats.mozilla.com/report/list?signature=js%3A%3Afrontend%3A%3ATokenStream%3A%3AgetTokenInternal%28%29 With those correlations: 90% (2080/2314) vs. 10% (9991/103848) BitGuard.dll 90% (2079/2314) vs. 2% (2301/103848) 2.6.1673.238 0% (1/2314) vs. 7% (7690/103848) 2.6.1694.246 Looks like both versions that are in circulation are crash-prone.

I verified that the fix from bug 927944 did not help this, and dmajor notes that this is an APPINIT DLL and so our blocklisting doesn't have any chance of blocking it. I filed bug 931907 to email affected users and recommend that they uninstall bitguard.

A new signature has been rising in recent days: bitguard.dll@0x16eb99 - correlations from Firefox 25: 100% (553/553) vs. 6% (2568/40292) BitGuard.dll 0% (0/553) vs. 0% (52/40292) 2.6.1673.238 0% (0/553) vs. 2% (917/40292) 2.6.1694.246 100% (553/553) vs. 4% (1599/40292) 2.7.1769.27

Currently the blocklist only targets 2.6.1694.246, so 2.7.1769.27 will be allowed even after we get around the AppInit issue. Should we increase the blocked version limit?

FWIW here are timestamps on the DLLs: 2.6.1694.246 Tue Oct 01 02:46:36 2013 2.7.1769.27 Tue Oct 22 08:09:35 2013 So it seems the releases are pretty frequent. We may be chasing this for a while if we only block using the most recent known version.

(In reply to Benjamin Smedberg [:bsmedberg] from comment #6) > We can block a DLL below a certain version, but we can't block a specific > range. So I can block bitguard.dll all the way up to 2.6.1694.246 but I > can't block 1694.246 while still allowing 1673.238. And also FWIW, I've seen various re-releases of 1673.238 in crash reports too. 2.6.1673.238 Tue Sep 10 07:33:48 2013 2.6.1673.238 Fri Sep 13 08:00:29 2013 2.6.1673.238 Wed Sep 18 23:51:15 2013

From what we know so far that this software does, I think we want to block it unconditionally independent of the version, actually. But I'd like the input of bsmedberg and relman on that.

If the work David is doing ends up being successful, and when it lands, we will want to block all versions of bitguard.dll

All-versions block if we want it

The status should have been updated here, we can update again after results from bug 932100 are in on central.

adding JS_WrapObject(JSContext*, JSObject**) as it is 58% correlated to bitguard. we'll have to keep on eye on it after blocking is enabled

Signature Rank in Nightly as of 2013-11-13: > [@ RtlAllocateHeap | bitguard.dll@0x16cf7c]: 0 crashes > [@ bitguard.dll@0x16d047]: 0 crashes > [@ bitguard.dll@0x16cce7]: 0 crashes > [@ RtlpLowFragHeapAllocFromContext | bitguard.dll@0x16cf7c]: 0 crashes > [@ RtlpLowFragHeapAllocFromContext | RtlAllocateHeap | bitguard.dll@0x16cf7c]: 0 crashes > [@ RtlAcquireSRWLockExclusive | RtlAllocateHeap | bitguard.dll@0x16cf7c]: 0 crashes > [@ bitguard.dll@0x16eb99]: 7 crashes > [@ JS_WrapObject(JSContext*, JSObject**)]: 0 crashes The only signature I'm seeing with 28.0a1 is [@ bitguard.dll@0x16eb99] and in pretty low volume. That said, the latest build ID with this signature is 20131109030206 which is 3 days before the blocklist landed on bug 932100. I don't think we can safely conclude yet if the blocklist is working.

checkin-needed is for the bitguard-allversions patch

Comment on attachment 830952 [details] [diff] [review] bitguard-allversions [Approval Request Comment] Bug caused by (feature/regressing bug #): External app User impact if declined: Top crasher on Windows Testing completed (on m-c, etc.): We only started blocking all versions in last night's nightly, so we don't yet have data on whether this successfully blocks bitguard.dll in the wild. Risk to taking this patch (and alternatives if risky): Low String or IDL/UUID changes made by this patch: None ** Also needs bug 932100 **

I am no longer seeing any of the signatures here on Nightly

I don't see any reports of this over the weekend, since it was fixed on Aurora.