Closed
Bug 1353785
Opened 7 years ago
Closed 7 years ago
Crash in @0x10019d82
Categories
(External Software Affecting Firefox :: Other, defect)
Tracking
(firefox-esr45 unaffected, firefox52 wontfix, firefox-esr52 unaffected, firefox53 unaffected, firefox54 unaffected, firefox55 unaffected)
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
firefox-esr45 | --- | unaffected |
firefox52 | --- | wontfix |
firefox-esr52 | --- | unaffected |
firefox53 | --- | unaffected |
firefox54 | --- | unaffected |
firefox55 | --- | unaffected |
People
(Reporter: philipp, Unassigned)
Details
(Keywords: crash)
Crash Data
This bug was filed from the Socorro interface and is report bp-bd833ee2-1186-47c5-9519-24c492170405. ============================================================= [Tracking Requested - why for this release]: this might not be actionable but nominating the bug for tracking to keep this on the radar. this is apparently a malware related startup crash signature that is rocketing up across channels during the last few hours (> 1.7k reports today). all the reports seem to have a randomly named .dll with version number 1.0.0.27567, so the normal blocklisting mechanism wouldn't work here.
Comment 1•7 years ago
|
||
I suppose we could extend the blocklisting mechanism to block a DLL with no debug info and version 1.0.0.27567.
Flags: needinfo?(aklotz)
Comment 2•7 years ago
|
||
Ugh. I'm not sure we can do anything about this. I don't feel comfortable blocking on those criteria.
Flags: needinfo?(aklotz)
Comment 3•7 years ago
|
||
Tracking this but it doesn't sound like it blocks 53 release since it's affecting all channels.
Comment 4•7 years ago
|
||
FWIW, I think that we could use that version information as a gateway to more intensive checks. We'd need a closer look at multiple copies (with distinct names) of the infringing binary. If the binary itself never changes, we could take any DLL with that version number and take a hash or something. Obviously I wouldn't want to do that for every DLL that is loaded, but if we gate that on other, faster checks then we could possibly make something work. Of course, if it's some sort of insane polymorphic DLL whose contents change along with the name, then that won't work. :-)
Comment 5•7 years ago
|
||
(In reply to Aaron Klotz [:aklotz] from comment #4) > FWIW, I think that we could use that version information as a gateway to > more intensive checks. > > We'd need a closer look at multiple copies (with distinct names) of the > infringing binary. If the binary itself never changes, we could take any DLL > with that version number and take a hash or something. Obviously I wouldn't > want to do that for every DLL that is loaded, but if we gate that on other, > faster checks then we could possibly make something work. > > Of course, if it's some sort of insane polymorphic DLL whose contents change > along with the name, then that won't work. :-) The faster checks could be the version and the absence of debug information (is it fast to read?).
Comment 6•7 years ago
|
||
Yeah that would be fast enough for our purposes. Though the absence of debug information isn't really a smoking gun. If we were to add that check, we would want to look at the version first. The pseudocode for this would be something like: if (!versionCheck) { // Continue load } if (debugInfo) { // Continue load } // Compute hash if (hash doesn't match) { // Continue load } // Else block But I don't want to commit to that until we can get our hands on some of these binaries.
Reporter | ||
Comment 7•7 years ago
|
||
the crash spike went away on its own...
Status: NEW → RESOLVED
Closed: 7 years ago
tracking-firefox53:
+ → ---
tracking-firefox54:
+ → ---
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•