Crash on print preview with Cylance malware "protection"
Categories
(External Software Affecting Firefox :: Other, defect)
Tracking
(firefox103 fixed)
| Tracking | Status | |
|---|---|---|
| firefox103 | --- | fixed |
People
(Reporter: bugs, Assigned: gsvelto)
References
Details
Crash Data
Attachments
(1 external file)
Cylance has been a repeated problem for me on multiple platforms, but I figured I should alert Mozilla to this in case it impacts people not on Nightly soon.
I a 100% repeatable crash of Firefox in Nightly with Cylance in the trace when opening a print-friendly popup window which has an onload window.print()
This worked without issue fairly recently, but I haven't yet bisected to see if it's due to a change in Firefox or a change in Cylance.
https://crash-stats.mozilla.org/report/index/3326924a-498c-4579-afa3-a84340220218
|
||
Comment 1•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Print Preview' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Oups. Thanks bugbot. I was looking for Print Preview in Firefox, but I guess I should've been looking Core.
|
|
||
Comment 3•4 years ago
|
||
The severity field is not set for this bug.
:alaskanemily, could you have a look please?
For more information, please visit auto_nag documentation.
|
||
Comment 4•4 years ago
|
||
There's not much to go on in the linked crash report. @nemo, any chance you can follow up on this
This worked without issue fairly recently, but I haven't yet bisected to see if it's due to a change in Firefox or a change in Cylance.
and let us know whether any specific Firefox change seems to be implicated here? Thanks!
Ugh. I do so hate bisecting, especially on Windows. But alright. hopefully it won't be too many builds.
I did confirm it's still happening with latest nightly. And thankfully it's really really easy to reproduce. Go to a site, hit ctrl-p, crash.
|
||
Comment 6•4 years ago
|
||
Gabriele, do you know who takes care of blocking dlls on windows? Maybe we could consider doing that here...
Sorry I haven't had time to bisect. It's still happening. It's just been an insane couple of work weeks so I couldn't really justify spending time bisecting. I just switched to testing print in chrome, even though chrome and firefox have totally different print bugs. (chrome has more IMO, frankly, since they are seriously bad at splitting up elements between pages)
|
Assignee | |
Comment 8•4 years ago
|
||
I do the blocking sometimes but in this case I'll defer to gcp because I can see there's more than one version being affected.
|
||
Comment 9•4 years ago
|
||
We only have 3 reports, for version 2.48.0.707.
It looks like it's possible to disable the "Memory Protection", which is the module that causes the crash:, or exclude it from injecting Firefox: https://cyberforcesecurityhelp.freshdesk.com/support/solutions/articles/44001409212-cylanceprotect-known-memory-protection-and-script-control-incompatibilities
|
|
||
Comment 10•4 years ago
|
||
Correction, there's more, including 2.45.0.574.
Citrix also documents enabling the Cylance "compatibility mode" for a safer hook: https://support.citrix.com/article/CTX232722
I don't think it's reasonable for us to do that on their behalf, though :P
|
|
||
Comment 11•4 years ago
|
||
I reached out to some contacts at Cylance about this last week but didn't get any reply. Feel free to block the crashing versions.
|
Reporter | |
Comment 12•4 years ago
|
||
Was this blocking by any chance rolled out? 'cause my nightly firefox, as of today's restart to update, is completely unresponsive, even in a clean profile. can't do anything in a url bar at all, browser console is blank. Search autosuggest filtering seems to work, but can't actually trigger the search.
|
|
||
Comment 13•4 years ago
|
||
|
||
Comment 14•4 years ago
|
||
Gabriele, could you take this one? The volume is low, but the report is on Nightly so I wonder if this could become a bigger problem.
|
|
Assignee | |
Comment 15•4 years ago
|
||
Sure
|
|
Assignee | |
Comment 16•4 years ago
|
||
Windows DLLBlocklist request form
- How were we aware of the problem?
Crash reports - What is a suspicious product causing the problem?
Cylance Protect - Is the product downloadable? If so, do we have a local repro?
No, it is a business-centric suite and cannot be downloaded. Additionally it was bought by a new vendor (Blackberry) and rebranded so it's unclear where to look for it. - Which OS versions does the problem occur on?
Windows 10 & 11 - Which process types does the problem occur on?
In the main process - What is the maximum version of the module in the crash reports?
2.48.0.707 - Is the issue fixed by a newer version of the product?
This appears to be the latest version so likely no, but it's unclear if the software is still being updated. - Do we have data about the module in the third-party-module ping?
Yes, this is the callstack we get from the third party ping:
0 firefox.exe!mozilla::freestanding::patched_LdrLoadDll(wchar_t*, unsigned long*, _UNICODE_STRING*, void**)+0x1ec
1 <unknown>+0xffffffff
- Do we know how the module is loaded?
I'm unable to tell which method is used - Describe your conclusion.
Given the lack of feedback from the vendor I'd block
|
|
Assignee | |
Comment 17•4 years ago
|
||
Note, this DLL is being injected in all processes but it appears to cause crashes only in the main one.
|
|
Assignee | |
Comment 18•4 years ago
|
||
|
||
Comment 19•4 years ago
|
||
|
|
||
Comment 20•4 years ago
|
||
| bugherder | ||
|
|
Reporter | |
Comment 21•4 years ago
|
||
BTW, just to confirm, nightlies no longer crash. Thanks!
|
|
Reporter | |
Comment 23•3 years ago
|
||
FYI, this crash is back. I don't know if it's because the version of Cylance changed, or Mozilla removed the blacklist, or something else happened.
I first noticed it a few days ago.
|
|
||
Comment 24•3 years ago
|
||
about:third-party should tell you the DLL's that got injected into Firefox. You may need to file a new bug for a new block. I guess this could also be solved by bug 1799458.
|
|
Reporter | |
Comment 25•3 years ago
|
||
Ok. I had filed a followup bug #1799562 with a crash ID.
|
|
Reporter | |
Comment 26•3 years ago
|
||
The crash ID should be sufficient for dll blocking right? I wanted to be sure I'd properly responded to the NEEDINFO since there wasn't any activity on either bug ☺
And, yay that you have some long-term fix on this. Sad that yet more sandboxing is needed due to other folks mangling your code.
|
|
Assignee | |
Comment 27•3 years ago
|
||
(In reply to nemo from comment #26)
The crash ID should be sufficient for dll blocking right? I wanted to be sure I'd properly responded to the NEEDINFO since there wasn't any activity on either bug ☺
Yes, it's fine, we can find the DLL info from there.
|
||
Updated•3 years ago
|
Description
•