Closed Bug 530914 Opened 13 years ago Closed 13 years ago
(Again with the _PR_MD_SEND blocking... This is the last one. For now at least.) So fgjk4wvb.dll is heavily correlated with crashes with a _PR_MD_SEND signature, which is one of our topcrashes. Looking at the last three days of data for the 3.5.5 release for the _PR_MD_SEND signature: 6% (72/1143) vs. 0% (123/93699) fgjk4wvb.dll (220.127.116.11) 9% (88/997) vs. 0% (156/91800) fgjk4wvb.dll (18.104.22.168) 14% (163/1158) vs. 0% (227/97540) fgjk4wvb.dll (22.214.171.124) In all cases it's version 126.96.36.199 that is the one correlated with the crash. (Gotta say that that's a suspicious looking version) It's also correlated with the following crashes (11/23 data from Firefox 3.5.5) calc.dll@0x3a4a|EXCEPTION_ACCESS_VIOLATION (69 crashes) 17% (12/69) vs. 0% (227/97540) fgjk4wvb.dll (188.8.131.52) rdolib.dll@0x3cc2|EXCEPTION_ACCESS_VIOLATION (62 crashes) 8% (5/62) vs. 0% (227/97540) fgjk4wvb.dll (184.108.40.206) rdolib.dll@0x3f0a|EXCEPTION_ACCESS_VIOLATION (60 crashes) 17% (10/60) vs. 0% (227/97540) fgjk4wvb.dll (220.127.116.11) Not quite sure what is up with being correlated with crashes in other dlls. Could be that all of fgjk4wvb.dll, calc.dll, rdolib.dll are malware (likely), and people prone to get infected with one of them, are infected with others. Or could be that these dlls play poorly together. Some simple googling showed that this is very likely a trojan of some sort. http://www.prevx.com/filenames/274180338196146072-X1/FGJK4WVB.DLL.html http://www.superantispyware.com/malwarefiles/FGJK4WVB.DLL.html http://www.greatis.com/appdata/d/f/fgjk4wvb.dll_Removal.htm http://www.incodesolutions.com/threats3/System32Rootfgjk4wvbdll.php
13 years ago
Assignee: nobody → morgamic
Severity: normal → minor
Priority: -- → P3
Target Milestone: --- → Future
I'd actually much rather we just use the DLL blocklist for this; dunno what the right component is for that, but reassigning to johnath.
Assignee: morgamic → johnath
Flags: blocking-firefox3.6? → blocking-firefox3.6+
That was what I intended yes. I think the conclusion last tuesday was that dll-blocking should go to the same component as addons-blocklists.
Flags: blocking-firefox3.6+ → wanted-firefox3.6+
Lets blocklist this one too, see data in comment 0
Assignee: johnath → jonas
Attachment #420169 - Flags: review?(johnath)
Attachment #420169 - Flags: review?(johnath) → review+
Comment on attachment 420169 [details] [diff] [review] Blocklist Motion carries. Clearly malware - no evidence of a legit vendor, fake-looking version number, and we're adding version-specific block to give a hypothetical vendor a way out. Thanks, Jonas.
Pushed to mozilla-central http://hg.mozilla.org/mozilla-central/rev/97612cf8b581 We likely want this on the 1.9.2 branch, but there's currently no way to request blocking since this component/product doesn't have that flag :( We also might want to let this bake a few days before taking on that branch
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
There doesn't seem to be a way to ask for 1.9.2 approval for this patch :( But I think we should take this on 1.9.2
blocking1.9.2: --- → ?
13 years ago
Attachment #420169 - Flags: approval18.104.22.168?
Comment on attachment 420169 [details] [diff] [review] Blocklist a=beltzner for 22.214.171.124
Attachment #420169 - Flags: approval126.96.36.199? → approval188.8.131.52+
Checked in to 184.108.40.206 http://hg.mozilla.org/releases/mozilla-1.9.2/rev/50fb75ba40a8
There is no way for QA to manual verify this blocked DLL. We would have to wait for the release and people upgrading to 3.6.2.
You need to log in before you can comment on or make changes to this bug.