944542 - DLL block request: spvc32.dll (Conduit)

Status: VERIFIED FIXED

(Toolkit :: Blocklist Policy Requests, defect)

Description

[Michael]

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.

Comment 1

[Jorge Villalobos [:jorgev] (he/him)]

Can you include information about the crashes?

Comment 2

[Michael]

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.

Comment 3

[(Away)]

Attempting to get this onto crash-stats via the workaround in bug 865146 comment 0.

Comment 4

[(Away)]

> 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

Comment 5

[bhavana bajaj [:bajaj]]

:bsmedberg/:dmajor is block listing the right path forward here ? If so, can either of you please help.

Comment 6

[(Away)]

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...

Comment 7

[Jorge Villalobos [:jorgev] (he/him)]

No, conversations with Conduit haven't really helped in the past. I'm okay with blocking it.

Comment 8

[(Away)]

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.

Comment 9

[(Away)]

Attachment: Blocklist spvc32.dll

Comment 10

[bhavana bajaj [:bajaj]]

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.

Comment 11

[Robert Kaiser]

(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).

Comment 12

[(Away)]

(In reply to Robert Kaiser (:[e-mail]) 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.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/a00e2b91ded1

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/a00e2b91ded1

Comment 15

[Robert Kaiser]

We should see to get this uplifted to aurora and beta.

Comment 16

[(Away)]

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

Comment 17

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/3c307b71fec5
https://hg.mozilla.org/releases/mozilla-beta/rev/0e77fc5ebdb3

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/0e77fc5ebdb3

Comment 19

[u279076]

Marking verified as I'm not seeing any reports of these signatures in Firefox 28, 29, or 30 builds in recent days on crashstats.

Comment 20

[(Away)]

(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)

Comment 21

[u279076]

(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

Comment 22

[(Away)]

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.

Comment 23

[(Away)]

(I imagine that their version check considers 27.0 and 27.0.1 to both be "27")

Comment 24

[u279076]

(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.