Closed Bug 1353785 Opened 7 years ago Closed 7 years ago

Crash in @0x10019d82

Categories

(External Software Affecting Firefox :: Other, defect)

x86
Windows 7
defect
Not set
critical

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.
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)
Ugh. I'm not sure we can do anything about this. I don't feel comfortable blocking on those criteria.
Flags: needinfo?(aklotz)
Tracking this but it doesn't sound like it blocks 53 release since it's affecting all channels.
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. :-)
(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?).
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.
the crash spike went away on its own...
You need to log in before you can comment on or make changes to this bug.