Closed Bug 944542 Opened 6 years ago Closed 6 years ago

DLL block request: spvc32.dll (Conduit)

Categories

(Toolkit :: Blocklist Policy Requests, defect)

defect
Not set

Tracking

()

VERIFIED FIXED
Tracking Status
firefox27 --- wontfix
firefox28 + verified
firefox29 + verified
firefox30 --- verified
b2g-v1.3 --- fixed

People

(Reporter: mz_mhs-ctb, Assigned: dmajor)

References

Details

(Keywords: crash, Whiteboard: [dll])

Crash Data

Attachments

(1 file)

DLL name: spvc32.dll
DLL versions to block: 2.8.11.9
Applications, versions, and platforms affected: Windows

Homepage and other references and contact info: www.conduit.com

Reasons: Malware, 1365 crashes in last 7 days.
Blocks: Conduit
Can you include information about the crashes?
The crash reason is: Unhandled C++ exception
It is calling RaiseException in KERNELBASE.dll

Example Stack:
0 	KERNELBASE.dll 	RaiseException 	
1 	SPVC32.dll 	SPVC32.dll@0x28bbe2 	
2 	SPVC32.dll 	SPVC32.dll@0x1589f3 	
3 	SPVC32.dll 	SPVC32.dll@0x1ca694 	
4 	SPVC32.dll 	SPVC32.dll@0x1bf8e7 	
5 	xul.dll 	nsThreadSyncDispatch::Run() 	xpcom/threads/nsThread.cpp
6 	xul.dll 	nsThread::ProcessNextEvent(bool,bool *) 	xpcom/threads/nsThread.cpp
7 	xul.dll 	NS_ProcessNextEvent(nsIThread *,bool) 	obj-firefox/xpcom/build/nsThreadUtils.cpp
8 	xul.dll 	nsThread::Shutdown() 	xpcom/threads/nsThread.cpp
9 	xul.dll 	nsDestroyThreadEvent::Run() 	netwerk/cache/nsCacheUtils.cpp
10 	xul.dll 	nsThread::ProcessNextEvent(bool,bool *) 	xpcom/threads/nsThread.cpp
11 	xul.dll 	NS_ProcessNextEvent(nsIThread *,bool) 	obj-firefox/xpcom/build/nsThreadUtils.cpp
12 	xul.dll 	nsThread::Shutdown() 	xpcom/threads/nsThread.cpp
13 	xul.dll 	nsDestroyThreadEvent::Run() 	netwerk/cache/nsCacheUtils.cpp
14 	xul.dll 	nsThread::ProcessNextEvent(bool,bool *) 	xpcom/threads/nsThread.cpp
15 	xul.dll 	NS_ProcessNextEvent(nsIThread *,bool) 	obj-firefox/xpcom/build/nsThreadUtils.cpp
16 	xul.dll 	nsThread::Shutdown() 	xpcom/threads/nsThread.cpp
17 	xul.dll 	mozilla::storage::`anonymous namespace'::AsyncCloseConnection::Run() 	storage/src/mozStorageConnection.cpp
18 	xul.dll 	nsThread::ProcessNextEvent(bool,bool *) 	xpcom/threads/nsThread.cpp
19 	xul.dll 	NS_ProcessNextEvent(nsIThread *,bool) 	obj-firefox/xpcom/build/nsThreadUtils.cpp
20 	xul.dll 	nsThread::Shutdown() 	xpcom/threads/nsThread.cpp
21 	xul.dll 	mozilla::storage::`anonymous namespace'::AsyncCloseConnection::Run() 	storage/src/mozStorageConnection.cpp
22 	xul.dll 	nsThread::ProcessNextEvent(bool,bool *) 	xpcom/threads/nsThread.cpp
23 	xul.dll 	NS_ProcessNextEvent(nsIThread *,bool) 	obj-firefox/xpcom/build/nsThreadUtils.cpp
24 	xul.dll 	nsThread::Shutdown() 	xpcom/threads/nsThread.cpp
25 	xul.dll 	mozilla::storage::`anonymous namespace'::AsyncCloseConnection::Run() 	storage/src/mozStorageConnection.cpp
26 	xul.dll 	nsThread::ProcessNextEvent(bool,bool *) 	xpcom/threads/nsThread.cpp
27 	xul.dll 	NS_ProcessPendingEvents(nsIThread *,unsigned int) 	obj-firefox/xpcom/build/nsThreadUtils.cpp
28 	xul.dll 	mozilla::ShutdownXPCOM(nsIServiceManager *) 	xpcom/build/nsXPComInit.cpp
29 	xul.dll 	ScopedXPCOMStartup::~ScopedXPCOMStartup() 	toolkit/xre/nsAppRunner.cpp
30 	xul.dll 	XREMain::XRE_main(int,char * * const,nsXREAppData const *) 	toolkit/xre/nsAppRunner.cpp
31 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp
32 	firefox.exe 	do_main 	browser/app/nsBrowserApp.cpp
33 	firefox.exe 	NS_internal_main(int,char * *) 	browser/app/nsBrowserApp.cpp
34 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp
35 	firefox.exe 	__tmainCRTStartup 	f:/dd/vctools/crt_bld/self_x86/crt/src/crtexe.c
36 	kernel32.dll 	BaseThreadInitThunk 	
37 	ntdll.dll 	__RtlUserThreadStart 	
38 	ntdll.dll 	_RtlUserThreadStart 	
from bp-53c470da-81ea-470f-be13-6441e2131127

more reports are 
bp-f86be0e5-7bc9-4a31-b7c6-f2c1c2131127
bp-50362a73-c0e0-4c72-ba8d-aff052131127



It seems that there are no more crashes past 25.0.1.
Crash Signature: [@ spvc32.dll@0x28e0e2]
Attempting to get this onto crash-stats via the workaround in bug 865146 comment 0.
Crash Signature: [@ spvc32.dll@0x28e0e2] → [@ spvc32.dll@0x28e0e2 ]
> It seems that there are no more crashes past 25.0.1.
Looks like this is tied to release channel and associated user base. It's currently the #16 crash on release (now 26) with no crashes on newer channels.

The crashes stop after DLL version 2.9.8.2:

Modules by versions Next Previous
Unhandled C++ Exception

100% (509/509) vs.   2% (2177/109336) SPVC32.dll
0% (0/509) vs.   0% (1/109336)
0% (0/509) vs.   0% (6/109336) 2.8.16.26
0% (0/509) vs.   0% (2/109336) 2.8.17.503
0% (0/509) vs.   0% (1/109336) 2.9.0.355
0% (0/509) vs.   0% (1/109336) 2.9.1.13
0% (0/509) vs.   0% (21/109336) 2.9.11.0
0% (0/509) vs.   0% (22/109336) 2.9.12.1
0% (0/509) vs.   0% (1/109336) 2.9.2.13
0% (0/509) vs.   0% (2/109336) 2.9.3.502
0% (0/509) vs.   0% (7/109336) 2.9.3.605
0% (0/509) vs.   0% (3/109336) 2.9.3.720
0% (0/509) vs.   0% (184/109336) 2.9.40.12
0% (1/509) vs.   0% (2/109336) 2.9.6.12
100% (508/509) vs.   2% (1924/109336) 2.9.8.2
Keywords: crash
Crash Signature: [@ spvc32.dll@0x28e0e2 ] → [@ spvc32.dll@0x28e0e2 ] [@ spvc32.dll@0x421f0e ]
Crash Signature: [@ spvc32.dll@0x28e0e2 ] [@ spvc32.dll@0x421f0e ] → [@ spvc32.dll@0x28e0e2 ] [@ spvc32.dll@0x421f0e ] [@ spvc32.dll@0x42243e ]
Crash Signature: [@ spvc32.dll@0x28e0e2 ] [@ spvc32.dll@0x421f0e ] [@ spvc32.dll@0x42243e ] → [@ spvc32.dll@0x28e0e2 ] [@ spvc32.dll@0x421f0e ] [@ spvc32.dll@0x42243e ] [@ spvc32.dll@0x42264e ]
Crash Signature: [@ spvc32.dll@0x28e0e2 ] [@ spvc32.dll@0x421f0e ] [@ spvc32.dll@0x42243e ] [@ spvc32.dll@0x42264e ] → [@ spvc32.dll@0x28e0e2 ] [@ spvc32.dll@0x421f0e ] [@ spvc32.dll@0x42243e ] [@ spvc32.dll@0x42264e ] [@ spvc32.dll@0x426dfe ] [@ spvc32.dll@0x426c9e ]
:bsmedberg/:dmajor is block listing the right path forward here ? If so, can either of you please help.
Flags: needinfo?(dmajor)
Flags: needinfo?(benjamin)
This is still occurring with very recent versions of spvc32, so there isn't a version cutoff that we could use -- we'd have to block all versions. 

    Timestamp:        Mon Jan 20 02:56:27 2014 (52DD00DB)
    File version:     2.9.60.20

Benjamin/Jorge, is it worthwhile talking to Conduit about this? The linked bugs give me the impression of no...
Flags: needinfo?(dmajor) → needinfo?(jorge)
No, conversations with Conduit haven't really helped in the past. I'm okay with blocking it.
Flags: needinfo?(jorge)
Apparently SearchProtect (spvc32) isn't something that you can go download on its own, but I did find it bundled with: http://download.cnet.com/Free-JPG-to-PDF/3000-10743_4-75732662.html

The extension uses an AppInit entry for SPVC32Loader.dll. The loader checks the version of firefox.exe and then loads SPVC32.dll if Firefox is version 27 or less. (This explains why we don't have hits for 28+) The loader then quickly goes away.

Maybe they update their version check when a new Firefox is released -- that would explain why we didn't see hits beyond 26 last month. If that is the case, then we would continue to see crashes when 28 rolls around.

Because of the version checks, it's tricky to test a blocklist fix on nightly, but I was able to do so by returning a fake result from VERSION!VerQueryValueW. Blocking spvc32.dll appears to be sufficient; the loader module is already gone by the time we load xul, so I don't think we need to worry about it separately.
Assignee: nobody → dmajor
Attachment #8371064 - Flags: review?(benjamin)
Flags: needinfo?(benjamin)
Nominating  tracking for branches in the hope of getting this uplifted as this was brought up in channel meeting as one of the top-crashers on all branches if we combined the signatures.
(In reply to David Major [:dmajor] from comment #8)
> Apparently SearchProtect (spvc32)

Ah, does that imply it's connected to bug 957258 (sprotector.dll)? If so, we have been seeing that spike as well in 26 and 27 (and I guess the block for both only works where we have the new early-blocking mechanisms in place, which IIRC we backed out for 27).
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #11)
> (In reply to David Major [:dmajor] from comment #8)
> > Apparently SearchProtect (spvc32)
> 
> Ah, does that imply it's connected to bug 957258 (sprotector.dll)?

I think they are just named similarly by coincidence. The details of the crashes are pretty different.
Attachment #8371064 - Flags: review?(benjamin) → review+
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/a00e2b91ded1
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
We should see to get this uplifted to aurora and beta.
Comment on attachment 8371064 [details] [diff] [review]
Blocklist spvc32.dll

Note that the crashing software does not currently load itself into versions newer than 27, but we expect that to change when 28 is released, so this uplift is anticipatory. 

[Approval Request Comment]
Bug caused by (feature/regressing bug #): external software
User impact if declined: crashes
Testing completed (on m-c, etc.): tested on a version-hacked m-c
Risk to taking this patch (and alternatives if risky): low
String or IDL/UUID changes made by this patch: none
Attachment #8371064 - Flags: approval-mozilla-beta?
Attachment #8371064 - Flags: approval-mozilla-aurora?
Attachment #8371064 - Flags: approval-mozilla-beta?
Attachment #8371064 - Flags: approval-mozilla-beta+
Attachment #8371064 - Flags: approval-mozilla-aurora?
Attachment #8371064 - Flags: approval-mozilla-aurora+
Keywords: checkin-needed
Crash Signature: [@ spvc32.dll@0x28e0e2 ] [@ spvc32.dll@0x421f0e ] [@ spvc32.dll@0x42243e ] [@ spvc32.dll@0x42264e ] [@ spvc32.dll@0x426dfe ] [@ spvc32.dll@0x426c9e ] → [@ spvc32.dll@0x28e0e2 ] [@ spvc32.dll@0x421f0e ] [@ spvc32.dll@0x42243e ] [@ spvc32.dll@0x42264e ] [@ spvc32.dll@0x426dfe ] [@ spvc32.dll@0x426c9e ] [@ spvc32.dll@0x44e8ce ]
Marking verified as I'm not seeing any reports of these signatures in Firefox 28, 29, or 30 builds in recent days on crashstats.
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #19)
> Marking verified as I'm not seeing any reports of these signatures in
> Firefox 28, 29, or 30 builds in recent days on crashstats.

Note that there were never crashes on >27 to begin with, because the extension does a version check against the highest known released FF. We expect that they will update their version check to include 28 upon its release, so this was a preventative fix. Can we keep an eye out to make sure this crash doesn't come back after the next round of releases?

(needinfo because I'm not sure how to flag this)
Flags: needinfo?(anthony.s.hughes)
(In reply to David Major [:dmajor] from comment #20)
> (In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #19)
> > Marking verified as I'm not seeing any reports of these signatures in
> > Firefox 28, 29, or 30 builds in recent days on crashstats.
> 
> Note that there were never crashes on >27 to begin with, because the
> extension does a version check against the highest known released FF.

That's odd because I definitely see a volume of these signuatures in 27.0.1:
https://crash-stats.mozilla.com/query/?product=Firefox&version=Firefox%3A27.0.1&range_value=1&range_unit=weeks&date=02%2F18%2F2014+21%3A00%3A00&query_search=signature&query_type=contains&query=spvc32.dll&reason=&release_channels=&build_id=&process_type=any&hang_type=any
Flags: needinfo?(anthony.s.hughes)
Yes because 27 is released. Their code currently loads on versions <= 27. After we release 28, I expect that they will update the extension to check for <= 28.
(I imagine that their version check considers 27.0 and 27.0.1 to both be "27")
(In reply to David Major [:dmajor] from comment #23)
> (I imagine that their version check considers 27.0 and 27.0.1 to both be
> "27")

I would imagine so. I'm just not sure we need to track this specifically though. We're doing daily crash-stats monitoring regardless. If this was a top issue post-release we'd see it.
Product: addons.mozilla.org → Toolkit
You need to log in before you can comment on or make changes to this bug.