Closed Bug 925459 Opened 11 years ago Closed 11 years ago

crashes related to bitguard.dll

Categories

(Firefox :: Extension Compatibility, defect)

25 Branch
x86
Windows 7
defect
Not set
critical

Tracking

()

VERIFIED FIXED
Firefox 28
Tracking Status
firefox24 --- wontfix
firefox25 + wontfix
firefox26 --- wontfix
firefox27 --- verified
firefox28 --- verified

People

(Reporter: tracy, Assigned: away)

References

Details

(Keywords: crash)

Crash Data

Attachments

(2 files)

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.
Crash Signature: [@ RtlAllocateHeap | bitguard.dll@0x16cf7c] [@ bitguard.dll@0x16d047] [@ bitguard.dll@0x16cce7] [@ RtlpLowFragHeapAllocFromContext | bitguard.dll@0x16cf7c] → [@ RtlAllocateHeap | bitguard.dll@0x16cf7c] [@ bitguard.dll@0x16d047] [@ bitguard.dll@0x16cce7] [@ RtlpLowFragHeapAllocFromContext | bitguard.dll@0x16cf7c] [@ RtlpLowFragHeapAllocFromContext | RtlAllocateHeap | bitguard.dll@0x16cf7c] [@ RtlAcquireSRW…
OS: All → Windows 7
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.
Attachment #816736 - Flags: approval-mozilla-beta+
Attachment #816736 - Flags: approval-mozilla-aurora+
Keywords: checkin-needed
-central checkin still needed.
Keywords: checkin-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.
Keywords: verifyme
https://hg.mozilla.org/mozilla-central/rev/05153aa83427
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 27
[@ 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?
Flags: needinfo?(benjamin)
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.
Assignee: benjamin → nobody
Flags: needinfo?(benjamin)
Keywords: verifyme
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.
Keywords: topcrash, verifyme
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
Depends on: 931907
Depends on: 932100
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
Crash Signature: RtlAcquireSRWLockExclusive | RtlAllocateHeap | bitguard.dll@0x16cf7c] → RtlAcquireSRWLockExclusive | RtlAllocateHeap | bitguard.dll@0x16cf7c] [@ bitguard.dll@0x16eb99 ]
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.
Flags: needinfo?(release-mgmt)
Flags: needinfo?(benjamin)
If the work David is doing ends up being successful, and when it lands, we will want to block all versions of bitguard.dll
Flags: needinfo?(release-mgmt)
All-versions block if we want it
Attachment #830952 - Flags: review?(benjamin)
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
Crash Signature: RtlAcquireSRWLockExclusive | RtlAllocateHeap | bitguard.dll@0x16cf7c] [@ bitguard.dll@0x16eb99 ] → RtlAcquireSRWLockExclusive | RtlAllocateHeap | bitguard.dll@0x16cf7c] [@ bitguard.dll@0x16eb99 ] [@ JS_WrapObject(JSContext*, JSObject**)]
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.
Attachment #830952 - Flags: review?(benjamin) → review+
checkin-needed is for the bitguard-allversions patch
Keywords: checkin-needed
Flags: needinfo?(benjamin)
https://hg.mozilla.org/mozilla-central/rev/f3063fb58ac6
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Keywords: verifyme
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 **
Attachment #830952 - Flags: approval-mozilla-aurora?
Target Milestone: Firefox 27 → Firefox 28
I am no longer seeing any of the signatures here on Nightly
Attachment #830952 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Keywords: checkin-needed
Whiteboard: Need Aurora checkin for bitguard-allversions after bug 932100 is checked in
https://hg.mozilla.org/releases/mozilla-aurora/rev/9cedd5ca03dc
Keywords: checkin-needed
Whiteboard: Need Aurora checkin for bitguard-allversions after bug 932100 is checked in
I don't see any reports of this over the weekend, since it was fixed on Aurora.
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: