Closed Bug 1294650 Opened 3 years ago Closed 3 years ago

follow up - startup crash in nsPrefBranch::GetIntPref (Websense Endpoint)

Categories

(External Software Affecting Firefox :: Other, defect, critical)

x86
Windows 7
defect
Not set
critical

Tracking

(firefox48blocking fixed, firefox49+ fixed, firefox-esr45 unaffected, firefox50+ fixed, firefox51 fixed, firefox52 fixed, firefox53 fixed, firefox54 fixed)

RESOLVED FIXED
Tracking Status
firefox48 blocking fixed
firefox49 + fixed
firefox-esr45 --- unaffected
firefox50 + fixed
firefox51 --- fixed
firefox52 --- fixed
firefox53 --- fixed
firefox54 --- fixed

People

(Reporter: Sylvestre, Assigned: jimm, NeedInfo)

References

(Blocks 2 open bugs)

Details

(Keywords: crash, topcrash, Whiteboard: [startupcrash][platform-rel-Forcepoint])

Crash Data

Attachments

(4 files, 3 obsolete files)

+++ This bug was initially created as a clone of Bug #1291738 +++

+++ This bug was initially created as a clone of Bug #828184 +++

My initial patch was incorrect, we have twice the same dll in the blocklist. 
We should have only one
Assignee: nobody → sledru
Attachment #8780426 - Flags: review?(benjamin) → review?(aklotz)
Comment on attachment 8780426 [details]
Bug 1294650 - Block the version of websense crashing 48 & 49. Followup, we already had this dll

https://reviewboard.mozilla.org/r/71158/#review68808
Comment on attachment 8780426 [details]
Bug 1294650 - Block the version of websense crashing 48 & 49. Followup, we already had this dll

https://reviewboard.mozilla.org/r/71160/#review68810
Attachment #8780426 - Flags: review?(aklotz) → review+
Pushed by sledru@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/94d311a8474c
Block the version of websense crashing 48 & 49. Followup, we already had this dll r=aklotz
Comment on attachment 8780426 [details]
Bug 1294650 - Block the version of websense crashing 48 & 49. Followup, we already had this dll

Approval Request Comment
[Feature/regressing bug #]: Outside change
[User impact if declined]: Startup crash
[Describe test coverage new/current, TreeHerder]: I don't have a windows to test, the patch is trivial
[Risks and why]: We are dealing with startup crashes, we cannot make it worst...
[String/UUID change made/needed]: None
Attachment #8780426 - Flags: approval-mozilla-release?
Attachment #8780426 - Flags: approval-mozilla-beta?
Attachment #8780426 - Flags: approval-mozilla-aurora?
Comment on attachment 8780426 [details]
Bug 1294650 - Block the version of websense crashing 48 & 49. Followup, we already had this dll

This patch fixes the crash by blocking websense. Take it in all 48/49/50.
Attachment #8780426 - Flags: approval-mozilla-release?
Attachment #8780426 - Flags: approval-mozilla-release+
Attachment #8780426 - Flags: approval-mozilla-beta?
Attachment #8780426 - Flags: approval-mozilla-beta+
Attachment #8780426 - Flags: approval-mozilla-aurora?
Attachment #8780426 - Flags: approval-mozilla-aurora+
the issue seems to still be ongoing according to the first incoming crash reports from 48.0.1 like https://crash-stats.mozilla.com/report/index/88d96bf4-87bb-40ec-83fd-be2ce2160818
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Oh... This is the same version (7.6.818.1) as we were supposed to block in my commit.
Benjamin, Aaron, any ideas? Not sure what to do. We received more than 1000 crashes (installation) last week. I am afraid that we will get 4 to 5 more crashes if we turn on updates for 48.0.1
Flags: needinfo?(benjamin)
Flags: needinfo?(aklotz)
We'd have to debug an Fx installation with this DLL present to know for sure, but typically if this happens then the DLL is being injected before the blocklist is able to catch it.
Flags: needinfo?(aklotz)
Flags: needinfo?(benjamin)
hi, are you aware about that issue (startup crashes with firefox 48 and websense - also see bug 1291738)?
Flags: needinfo?(mgosai)
Flags: needinfo?(mghadiri)
Aaron, philipp mentioned this two comments:
https://bugzilla.mozilla.org/show_bug.cgi?id=1291738#c23 and https://bugzilla.mozilla.org/show_bug.cgi?id=1181091#c59
Would they be acceptable for you?
(In reply to Sylvestre Ledru [:sylvestre] from comment #15)
> Aaron, philipp mentioned this two comments:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1291738#c23 and
> https://bugzilla.mozilla.org/show_bug.cgi?id=1181091#c59
> Would they be acceptable for you?

Dropping a dummy dll into our directory would work (assuming that they're not loading with an absolute path, which appears to be the case based on those comments), but it's not particularly sustainable as a fix. I doubt that we want to be dropping dummy files into our directory every time another DLL like this shows up.
Aaron, as a temporary workaround for a 48.0.2, would you sign off on this? (or implement it ;)
Instead of pushing this to everyone, can we check for the existance of websense and create this dummy dll dynamically? Perhaps we can use the webcompat system add-on to push this fix out to affected systems before re-enabling updates. In this way we can remove the hack once websense pushes a fix (assuming that they do).
(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #18)
> Instead of pushing this to everyone, can we check for the existence of
> websense and create this dummy dll dynamically? Perhaps we can use the
> webcompat system add-on to push this fix out to affected systems before
> re-enabling updates. In this way we can remove the hack once websense pushes
> a fix (assuming that they do).

This would require write privs to the program files folder. Usually we have to elevate to write to this path so I don't think this is possible.

The dummy dll seems ok, although I worry about breaking websense, causing crashes on the system, etc.. That said though those two testers commented it worked so, maybe. I ping;d kev on irc, he's going to try to reach out to these guys. In the mean time we can put together and test a fix.

Are there testers tuned in here who have this software and can help test a fix?
Maybe I jumped to a conclusion - does the 'webcompat system add-on' have the ability to update files in program files?
Hey Sander, any chance you could zip up a copy of qipcap.dll and attach it here?
Flags: needinfo?(sander+bugzilla)
I have an older copy from bug 1181091. dmajor did some debugging of this in that bug as well. We passed on trying to work around it.
Flags: needinfo?(sander+bugzilla)
Attached file qipcap.dll
Attached file qipcap64.dll
Attached patch dummy dll wip (obsolete) — Splinter Review
Not a huge fan of this dummy dll idea. it's a bit of a hack that can easily be worked around by the 3rd party vendor. Spoke to aklotz, he feels the same. It would be better to work with the vendor to prevent this from happening (and get a quick fix out if possible for 48).

I'll get a try build of this dll trick patch going so we can test to see if it works.

There may be some things we can do to improve our blocklisting on new os as well (bug 1291353) which I'll insert into the platform integration teams work queue.
> It would be better to work with the vendor to prevent this from happening (and get a quick fix out if 
> possible for 48).
I wish we could get in touch with someone who understands our pain. For now, we haven't been able to find this contact (as far as i know). Even if they fix the issue, it is going to take a few weeks before all their users are updated.

The dll workaround is crap, for sure. However, it is a good mitigation until we:
* work with websense
* have a better mechanism to block them
What's the time frame I'm working with here for 48.0.2?
Flags: needinfo?(sledru)
It would be great to have 48.0.2 live middle of next week.
Having a patch for Monday would be great.
Flags: needinfo?(sledru)
Attached patch patch (obsolete) — Splinter Review
Assignee: sledru → jmathies
Attachment #8782651 - Attachment is obsolete: true
Sanders, would you mind taking these for a spin to see if the problem is resolved?
Flags: needinfo?(sander+bugzilla)
Ryan, can softvision help us here at all? Not sure if they have access to this software. If they do, maybe they could try to reproduce and then test these builds.
Flags: needinfo?(ryanvm)
Florin, does SV have access to Websense?
Flags: needinfo?(ryanvm) → needinfo?(florin.mezei)
I am unable to test for the next week due to holiday - besides we dropped the endpoint software in favor of an appliance (although I still have access to it). Will ping our partner to ask for collaboration.
Flags: needinfo?(sander+bugzilla)
(In reply to Ryan VanderMeulen [:RyanVM] from comment #34)
> Florin, does SV have access to Websense?

I see Mihai tried to verify the crash yesterday, without success (see https://bugzilla.mozilla.org/show_bug.cgi?id=1291738#c30). 

Mihai can you provide some details here, as to what you've tried, and how/if we have access to Websense?
Flags: needinfo?(florin.mezei) → needinfo?(mihai.boldan)
I was unable to replicate the startup crash because there's no Websense Endpoint client available for download anymore. AFAIK, other than using an actual Forcepoint license, there's no trial available for this software on the web.

I'm currently discussing options with our IT dept. but it might take a while. Is there someone with Websense installed that could confirm this fix?
Flags: needinfo?(mihai.boldan)
Jim, can we land that at least on nightly (and maybe aurora) so that we get some testing coverage during the week end? Thanks
Flags: needinfo?(jmathies)
(In reply to Mihai Boldan, QA [:mboldan] from comment #37)
> I was unable to replicate the startup crash because there's no Websense
> Endpoint client available for download anymore. AFAIK, other than using an
> actual Forcepoint license, there's no trial available for this software on
> the web.
> 
> I'm currently discussing options with our IT dept. but it might take a
> while. Is there someone with Websense installed that could confirm this fix?

I have Websense installed, I can test it when it lands on nightly
Hey, can you test with this try build? 

https://archive.mozilla.org/pub/firefox/try-builds/jmathies@mozilla.com-40495b7a5aa766705d61f9712f079dc2affb6fe4/try-win32/
Flags: needinfo?(jmathies) → needinfo?(jcbodez)
(In reply to Sylvestre Ledru [:sylvestre] from comment #38)
> Jim, can we land that at least on nightly (and maybe aurora) so that we get
> some testing coverage during the week end? Thanks

Nightly would be ok I guess. There's no point in uplifting to release and generating a point release without confirmation it addresses the issue though.
Attached patch patch (obsolete) — Splinter Review
Attachment #8782865 - Attachment is obsolete: true
Attachment #8783358 - Flags: review?(aklotz)
Comment on attachment 8783358 [details] [diff] [review]
patch

Review of attachment 8783358 [details] [diff] [review]:
-----------------------------------------------------------------

::: toolkit/library/dummydll/dummydll.cpp
@@ +8,5 @@
> +  HANDLE hinstDLL,
> +  DWORD dwReason,
> +  LPVOID lpvReserved
> +)
> +{

Nit: It might be nice to include a call to DisableThreadLibraryCalls here.
Attachment #8783358 - Flags: review?(aklotz) → review+
Pushed by jmathies@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/d332de446548
Install shim 'qipcap' dlls into the Firefox folder to circumvent dll injection by the 3rd party Websense product. r=aklotz
One concern I thought of is with updates, if this DLL gets loaded by another process and held, it could trigger restarts during software updating. Our update mechanism should be able to deal with this but it would make updating more cumbersome.
(In reply to Mihai Boldan, QA [:mboldan] from comment #37)
> I was unable to replicate the startup crash because there's no Websense
> Endpoint client available for download anymore. AFAIK, other than using an
> actual Forcepoint license, there's no trial available for this software on
> the web.
> 
> I'm currently discussing options with our IT dept. but it might take a
> while. Is there someone with Websense installed that could confirm this fix?

FWIW, I looked all over the web for an orphaned installer of this websense product with no luck. The company was purchased on January 2016 and rebranded to Forcepoint. Apparently they don't provide free trials anymore.
ok, looks like we have to take into aurora & beta at least and see what happens... :/
Andrei, I know this is a hard and painful but could you help to reproduce the crash and see if this is fixed in the try builds? Thanks
Flags: needinfo?(andrei.vaida)
(In reply to Sylvestre Ledru [:sylvestre] from comment #48)
> Andrei, I know this is a hard and painful but could you help to reproduce
> the crash and see if this is fixed in the try builds? Thanks

Unfortunately, I can only confirm what Mihai (Comment 37) and Jim (Comment 46) said about the websense product availability: there's no way for us to test this, because we can't find an installer for it anywhere.

We'd gladly help out here if, perhaps, someone could provide a trial installer for it.
Flags: needinfo?(andrei.vaida)
Is the fix included in the latest nightly so I can test it ?
(In reply to Pulsebot from comment #44)
> Pushed by jmathies@mozilla.com:
> https://hg.mozilla.org/integration/mozilla-inbound/rev/d332de446548
> Install shim 'qipcap' dlls into the Firefox folder to circumvent dll
> injection by the 3rd party Websense product. r=aklotz

This didn't merge into today's build. I'll get that done and we'll trigger a new nightly build.
Pushed by jmathies@mozilla.com:
https://hg.mozilla.org/mozilla-central/rev/bad612fd3ab0
Install shim 'qipcap' dlls into the Firefox folder to circumvent dll injection by the 3rd party Websense product. r=aklotz a=jimm
https://hg.mozilla.org/mozilla-central/rev/d332de446548
Status: REOPENED → RESOLVED
Closed: 3 years ago3 years ago
Resolution: --- → FIXED
I asked releng (rail, thanks!) to restart a build of nightly with this fix.
Jim, could you fill the uplift requests to all branches so that we are ready once it is verified. Thanks
Flags: needinfo?(jmathies)
I can confirm that last nightly is not crashing on the same pc on which Firefox 48.0.1 is.
Thanks for the fix.
Attached patch patchSplinter Review
patch that landed.
Attachment #8783358 - Attachment is obsolete: true
Flags: needinfo?(jmathies)
Attachment #8784089 - Flags: review+
Comment on attachment 8784089 [details] [diff] [review]
patch

Approval Request Comment
[Feature/regressing bug #]:
Crash caused by 3rd party security suite code injection. Not our bug.
[User impact if declined]:
Crashy startup for some users with the security suite installed.
[Describe test coverage new/current, TreeHerder]:
work around is on nightly which was tested by a single user who confirmed the fix works.
[Risks and why]:
medium risk, patch adds a dummy dll to our release install. stand alone this shouldn't cause any problems, hard to say what will happen though since the dll gets loaded by a 3rd party product. we do have confirmation that it addresses the startup crash caused by the security suite.
[String/UUID change made/needed]:
none
Attachment #8784089 - Flags: approval-mozilla-release?
Attachment #8784089 - Flags: approval-mozilla-beta?
Attachment #8784089 - Flags: approval-mozilla-aurora?
Flags: needinfo?(jcbodez)
Comment on attachment 8784089 [details] [diff] [review]
patch

Taking it to all branches to test + build 48.0.2
Attachment #8784089 - Flags: approval-mozilla-release?
Attachment #8784089 - Flags: approval-mozilla-release+
Attachment #8784089 - Flags: approval-mozilla-beta?
Attachment #8784089 - Flags: approval-mozilla-beta+
Attachment #8784089 - Flags: approval-mozilla-aurora?
Attachment #8784089 - Flags: approval-mozilla-aurora+
jcleval: many many thanks :)
(In reply to jcleval from comment #57)
> I can confirm that last nightly is not crashing on the same pc on which
> Firefox 48.0.1 is.
> Thanks for the fix.

Was nightly crashing you before this fix landed? If you weren't testing Nightly prior to the fix landing, could you try installing http://ftp.mozilla.org/pub/firefox/nightly/2016/08/2016-08-22-03-04-24-mozilla-central/firefox-51.0a1.en-US.win32.installer.exe to see if it crashes?

Alternatively, could you test the candidate beta build with the fix? http://ftp.mozilla.org/pub/firefox/candidates/48.0.2-candidates/build1/win32/en-US/Firefox%20Setup%2048.0.2.exe

Thanks
Flags: needinfo?(jcbodez)
We have only one crash for now. 
https://crash-stats.mozilla.com/report/index/b5322f8f-89ef-4785-9068-efbfe2160824

Not panicking but if we get more, we should disable updates.
Hi.
I wasn't using nightly before the fix.
However I just upgraded FF 48.0.1, which was crashing on this pc, to 48.0.2, and the installation went well, no startup crash.
More crashes in 48.0.2. (Not mine, don't run the software.)

Would adding to nsPrefBranch::GetIntPref a check of _retval == 0x2 be an (unideal) avoidance to the crash?
With a bunch of crashes, I don't think we can say that we fixed it.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to Sylvestre Ledru [:sylvestre] from comment #67)
> With a bunch of crashes, I don't think we can say that we fixed it.

In the module list for these, I see QIPCAP.dll loaded from system32, as well as QIPOverlay.dll, both with proper version info so I don't think our shim dll is getting picked up.
Depends on: 1298157
debugging one of these dumps, I see the pointer for nsPrefBranch::GetIntPref's _retval pointing into the memory space of this 3rd party dll. so if this stack is valid then they either hooked our api or are calling it with invalid parameters.

It would be great if we could find an in-house test case/machine for this, then we could trace back to the landing that caused their software to fault.
(In reply to Jim Mathies [:jimm] from comment #19)
> I ping;d kev on irc, he's going to try to reach out to
> these guys.

Any update here? (Note they have a twitter account https://twitter.com/forcepointsec)
We have a contact with them (started)
See Also: → 1298503
User on SUMO reported crashes with Websense and FF48.0.2:
https://support.mozilla.org/fr/questions/1136342
They stated the following:
"This issue was fixed in our latest release (8.2.5) and we are checking whether this fix will be backported to older versions."
Jim, do you think we should back this change to add the dll, out from 49 and above, since it didn't work in 48.0.2?
Flags: needinfo?(jmathies)
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #74)
> Jim, do you think we should back this change to add the dll, out from 49 and
> above, since it didn't work in 48.0.2?

Yes, this is covered by bug 1298157.
Flags: needinfo?(jmathies)
The dll is backed out from 49 in bug 1298157 now. I don't think this should block 49 anymore. 
Websense users who are still on pre-48 versions will not yet update to 49, but can still update to 47.0.1.
 
We may re-assess this in a few weeks and can change the update rules based on feedback from websense about their user update rate, since users with their latest update should get the fix that will prevent startup crash. I expect by 50 release we should be able to bring pre-48 users up to 50.
For followup, we will want to know,
- How many users are held back on the blocked websense versions (I think releng can tell us this)
- Has websense shipped its fixes and do we know the proportion/# of users on the fixed versions vs. the old ones?
- Once it hits some level we think it acceptable, to be determined, Then we ship something that allows pre-48 users update to 49. 
We may want to file that as a new bug or bugs.
Depends on: 1304783
Blocks: websense
Crash volume for signature 'PREF_GetIntPref':
 - nightly (version 52): 0 crashes from 2016-09-19.
 - aurora  (version 51): 7 crashes from 2016-09-19.
 - beta    (version 50): 61 crashes from 2016-09-20.
 - release (version 49): 1261 crashes from 2016-09-05.
 - esr     (version 45): 1 crash from 2016-06-01.

Crash volume on the last weeks (Week N is from 10-03 to 10-09):
            W. N-1  W. N-2
 - nightly       0       0
 - aurora        7       0
 - beta         52       9
 - release     410     851
 - esr           0       0

Affected platforms: Windows, Mac OS X

Crash rank on the last 7 days:
           Browser   Content     Plugin
 - nightly
 - aurora  #184
 - beta    #278
 - release #126      #468
 - esr
See Also: → 1310240
Whiteboard: [startupcrash] → [startupcrash][platform-rel-Forcepoint]
Crash volume for signature 'PREF_GetIntPref':
 - nightly (version 52): 3 crashes from 2016-09-19.
 - aurora  (version 51): 23 crashes from 2016-09-19.
 - beta    (version 50): 214 crashes from 2016-09-20.
 - release (version 49): 1663 crashes from 2016-09-05.
 - esr     (version 45): 1 crash from 2016-07-25.

Crash volume on the last weeks (Week N is from 10-17 to 10-23):
            W. N-1  W. N-2  W. N-3  W. N-4
 - nightly       0       3       0       0
 - aurora       12       3       7       0
 - beta         65      78      52       9
 - release     140     194     410     851
 - esr           0       0       0       0

Affected platforms: Windows, Mac OS X

Crash rank on the last 7 days:
           Browser   Content     Plugin
 - nightly
 - aurora  #91
 - beta    #590
 - release #391      #678
 - esr
Hi Jim, I would prefer to add the shim in 50 if that is show the 49.0.1+ dot releases were pushed out. What do you think?
Flags: needinfo?(jmathies)
I've asked Wes to help. See https://bugzilla.mozilla.org/show_bug.cgi?id=1304783#c4
Flags: needinfo?(jmathies)
Removing the blocking flag, still keeping it tracked for 50.
Pushed by kwierso@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/bba5ddb15392
Install shim 'qipcap' dlls into the Firefox folder to circumvent dll injection by the 3rd party Websense product. r=aklotz a=ritu
Do we really need this on trunk given the changes that have landed there RE: DLL injection?
Flags: needinfo?(benjamin)
Possibly yes. My code makes Firefox less easily hackable, but it's not going to be perfect.
Flags: needinfo?(benjamin)
https://hg.mozilla.org/mozilla-central/rev/bba5ddb15392
Status: REOPENED → RESOLVED
Closed: 3 years ago3 years ago
Resolution: --- → FIXED
I have tested this issue on the latest Beta and Release channel builds on a Windows 10 (x32 & x64) machine. 
I have experienced crashes on all of the following scenarios:

WebSense Endpoint Package 8.2.2324 on Firefox 51.0.1 build 2 x64 - Windows 10 x64
WebSense Endpoint Package 8.2.2324 on Firefox 51.0.1 build 2 x32 - Windows 10 x64
WebSense Endpoint Package 8.2.2324 on Firefox 51.0.1 build 2 x32 - Windows 10 x32

WebSense Endpoint Package 8.2.2324 on Firefox 51.0.1 build 3 x64 - Windows 10 x64
WebSense Endpoint Package 8.2.2324 on Firefox 51.0.1 build 3 x32 - Windows 10 x64
WebSense Endpoint Package 8.2.2324 on Firefox 51.0.1 build 3 x32 - Windows 10 x32
- qipcap64.dll file is present in the installation folder of Fx 51.0.1 build 3 x64
- qipcap.dll file is present in the installation folder of Fx 51.0.1 build 3 x32

WebSense Endpoint Package 8.2.2324 on Firefox 52.0b1 build 2 x64 - Windows 10 x64
WebSense Endpoint Package 8.2.2324 on Firefox 52.0b1 build 2 x32 - Windows 10 x64
WebSense Endpoint Package 8.2.2324 on Firefox 52.0b1 build 2 x32 - Windows 10 x32
Related to the test results above, this is consistent with previous testing of Firefox versions with the shim dll applied (e.g. 48.0.2): 
- the shim dll fixes crashes like [1] and [2], reproduced with a very old endpoint version (v8.0.2076)
- the shim dll does not fix crashes like [@ PREF_GetIntPref ] - that we track here - with endpoint version v8.2.2324 (commercial version 8.2)
- some newer endpoint versions do NOT cause a crash, regardless of the presence of a shim dll or not (e.g. commercial version 8.2.5_2424 = 8.2.5.2424, or commercial version 8.3 = 8.3.2509)

So in fact the shim dll seems to have the same effect as in 48.0.2 for example, where it prevents startup crashes for users with some old Websense versions installed, but still cannot prevent the crash that we track here for some relatively newer Websense versions (e.g. 8.2).

More details on Websense testing until today can be found here - https://docs.google.com/spreadsheets/d/18n8NEimajNpnGRHdQsrrnyJ-Ufgvmpz-AXCUpVaFRMk/edit#gid=0.

[1] - [@ @0x0 | mozilla::ShutdownXPCOM] - https://crash-stats.mozilla.com/report/index/25e534a3-2e09-4348-ac5e-8e5952160914
[2] - [@ @0x0 | nsJSCID::GetService ] - https://crash-stats.mozilla.com/report/index/66153288-5453-46b1-bf86-1381f2160914
50.1.0 with Websense (ForcePoint) - 8.2 Build 2424 works great on 32bit Win 7, while the same configuration is not working on 51.0.1(In reply to Florin Mezei, QA (:FlorinMezei) from comment #91)
> Related to the test results above, this is consistent with previous testing
> of Firefox versions with the shim dll applied (e.g. 48.0.2): 
> - the shim dll fixes crashes like [1] and [2], reproduced with a very old
> endpoint version (v8.0.2076)
> - the shim dll does not fix crashes like [@ PREF_GetIntPref ] - that we
> track here - with endpoint version v8.2.2324 (commercial version 8.2)
> - some newer endpoint versions do NOT cause a crash, regardless of the
> presence of a shim dll or not (e.g. commercial version 8.2.5_2424 =
> 8.2.5.2424, or commercial version 8.3 = 8.3.2509)
> 
> So in fact the shim dll seems to have the same effect as in 48.0.2 for
> example, where it prevents startup crashes for users with some old Websense
> versions installed, but still cannot prevent the crash that we track here
> for some relatively newer Websense versions (e.g. 8.2).
> 
> More details on Websense testing until today can be found here -
> https://docs.google.com/spreadsheets/d/18n8NEimajNpnGRHdQsrrnyJ-Ufgvmpz-
> AXCUpVaFRMk/edit#gid=0.
> 
> [1] - [@ @0x0 | mozilla::ShutdownXPCOM] -
> https://crash-stats.mozilla.com/report/index/25e534a3-2e09-4348-ac5e-
> 8e5952160914
> [2] - [@ @0x0 | nsJSCID::GetService ] -
> https://crash-stats.mozilla.com/report/index/66153288-5453-46b1-bf86-
> 1381f2160914

I have WIN7 32bit with Forcepoint 8.2 build 2424. It works with 50.1.0 but not with 51.0.1
(In reply to Florin Mezei, QA (:FlorinMezei) from comment #91)
> More details on Websense testing until today can be found here -
> https://docs.google.com/spreadsheets/d/18n8NEimajNpnGRHdQsrrnyJ-Ufgvmpz-
> AXCUpVaFRMk/edit#gid=0.

Do you have any details regarding compatibility with 51?
(In reply to Ryan VanderMeulen [:RyanVM] from comment #86)
> Do we really need this on trunk given the changes that have landed there RE:
> DLL injection?

(In reply to Benjamin Smedberg [:bsmedberg] from comment #87)
> Possibly yes. My code makes Firefox less easily hackable, but it's not going
> to be perfect.

the good news is, that the crashes with involvement of the websense module really seem to stop in 53: https://crash-stats.mozilla.com/search/?proto_signature=~qipcap.dll&release_channel=aurora&date=%3E%3D2016-10-01T00%3A00%3A00.000Z&_sort=-date&_facets=signature&_facets=version&_facets=build_id&_facets=platform_pretty_version&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-version :))
Is there anything actionable left to do in this bug for 52/53? The shim DLL was landed across all branches in bug 1304783. And AFAICT, any future mitigations we land on our end aren't likely to be upliftable.
Flags: needinfo?(sledru)
(In reply to Ryan VanderMeulen [:RyanVM] from comment #95)
> Is there anything actionable left to do in this bug for 52/53? The shim DLL
> was landed across all branches in bug 1304783. And AFAICT, any future
> mitigations we land on our end aren't likely to be upliftable.

There is bug 1329692, we are protected from the websense crashes in the version after the version that will contain those changes.
I think we are as good as we can be here :/
Flags: needinfo?(sledru)
I'm setting the tracking flags to fixed to get this specific bug off the radar in that case. We're obviously still tracking ongoing Websense issues via bug 1305847 and its dependencies, however.
You need to log in before you can comment on or make changes to this bug.