614966 - Various crashes with VKSaver 2.2 (vksaver.dll@...) or VKSaver 3.1 (vksaver.dll@0x3d66, vksaver3.dll@0x2e55)

Status: RESOLVED WONTFIX

(Toolkit :: Blocklist Policy Requests, defect)

Description

[Scoobidiver (away)]

This is a residual crash signature that exists in 3.6 and trunk builds.
It is #43 top crasher in 4.0b8pre for the last week.

86% of FF 3.6.12 crashes with send signature have vksaver.dll 2.2.2.0 loaded.
98% of FF 4.0b8pre crashes with send signature have vksaver.dll 2.2.2.0 loaded.
Version 2.2.2.0 is the latest one.

Stack traces are similar to the ones of bug 593842, bug 467167, and bug 602373.

Signature	send
UUID	775ff3b3-b491-4215-a76e-70b7d2101126
Time 	2010-11-26 07:41:48.381310
Uptime	7
Last Crash	9 seconds before submission
Install Age	4760 seconds (1.3 hours) since version was first installed.
Product	Firefox
Version	4.0b8pre
Build ID	20101125030318
Branch	2.0
OS	Windows NT
OS Version	5.1.2600 Service Pack 3
CPU	x86
CPU Info	AuthenticAMD family 15 model 36 stepping 2
Crash Reason	EXCEPTION_ACCESS_VIOLATION_WRITE
Crash Address	0x33575885
App Notes 	AdapterVendorID: 0000, AdapterDeviceID: 0000
MSAFD Irda [IrDA] : 2 : 1 :
MSAFD Tcpip [TCP/IP] : 2 : 1 : %SystemRoot%\system32\mswsock.dll
MSAFD Tcpip [UDP/IP] : 2 : 2 : %SystemRoot%\system32\mswsock.dll
MSAFD Tcpip [RAW/IP] : 2 : 3 : %SystemRoot%\system32\mswsock.dll
RSVP UDP Service Provider : 6 : 2 : %SystemRoot%\system32\rsvpsp.dll
RSVP TCP Service Provider : 6 : 1 : %SystemRoot%\system32\rsvpsp.dll
MSAFD NetBIOS [\Device\NetBT_Tcpip_{198F78B7-EE3F-4897-93F5-741746D6493D}] SEQPACKET 0 : 2 : 5 : %SystemRoot%\system32\mswsock.dll
MSAFD NetBIOS [\Device\NetBT_Tcpip_{198F78B7-EE3F-4897-93F5-741746D6493D}] DATAGRAM 0 : 2 : 2 : %SystemRoot%\system32\mswsock.dll
MSAFD NetBIOS [\Device\NetBT_Tcpip_{32E4EA0D-5565-4771-883C-EA25E4239A44}] SEQPACKET 1 : 2 : 5 : %SystemRoot%\system32\mswsock.dll
MSAFD NetBIOS [\Device\NetBT_Tcpip_{32E4EA0D-5565-4771-883C-EA25E4239A44}] DATAGRAM 1 : 2 : 2 : %SystemRoot%\system32\mswsock.dll
MSAFD NetBIOS [\Device\NetBT_Tcpip_{D20A552D-3BB4-4

Frame 	Module 	Signature [Expand] 	Source
0 	ws2_32.dll 	send 	
1 	vksaver.dll 	vksaver.dll@0x5d4a 	
2 	nspr4.dll 	_PR_MD_SEND 	nsprpub/pr/src/md/windows/w95sock.c:357
3 	nspr4.dll 	SocketSend 	nsprpub/pr/src/io/prsocket.c:681
4 	nspr4.dll 	SocketWrite 	nsprpub/pr/src/io/prsocket.c:701
5 	nspr4.dll 	PR_SetPollableEvent 	nsprpub/pr/src/io/prpolevt.c:232
6 	xul.dll 	nsSocketTransportService::OnDispatchedEvent 	netwerk/base/src/nsSocketTransportService2.cpp:528
7 	xul.dll 	nsThread::Dispatch 	xpcom/threads/nsThread.cpp:433
8 	xul.dll 	nsSocketTransportService::Dispatch 	netwerk/base/src/nsSocketTransportService2.cpp:124
9 	xul.dll 	nsHttpConnectionMgr::PostEvent 	netwerk/protocol/http/nsHttpConnectionMgr.cpp:181
10 	xul.dll 	nsHttpConnectionMgr::AddTransaction 	netwerk/protocol/http/nsHttpConnectionMgr.cpp:249
11 	xul.dll 	nsHttpChannel::Connect 	netwerk/protocol/http/nsHttpChannel.cpp:321
12 	xul.dll 	nsHttpChannel::OnNormalCacheEntryAvailable 	netwerk/protocol/http/nsHttpChannel.cpp:2229
13 	xul.dll 	nsHttpChannel::OnCacheEntryAvailable 	netwerk/protocol/http/nsHttpChannel.cpp:4400
14 	xul.dll 	nsCacheListenerEvent::Run 	netwerk/cache/nsCacheService.cpp:1441
15 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:626
16 	nspr4.dll 	_MD_CURRENT_THREAD 	nsprpub/pr/src/threads/combined/prulock.c:404
17 	nspr4.dll 	_MD_CURRENT_THREAD 	nsprpub/pr/src/threads/combined/prulock.c:404
18 	xul.dll 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:110
19 	xul.dll 	MessageLoop::RunHandler 	ipc/chromium/src/base/message_loop.cc:202
20 	xul.dll 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:176
21 	xul.dll 	nsBaseAppShell::Run 	widget/src/xpwidgets/nsBaseAppShell.cpp:181
22 	xul.dll 	xul.dll@0xb0bcbb 	
23 	xul.dll 	nsAppStartup::Run 	toolkit/components/startup/src/nsAppStartup.cpp:191
24 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3691
25 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:128
26 	firefox.exe 	__tmainCRTStartup 	obj-firefox/memory/jemalloc/crtsrc/crtexe.c:591
27 	kernel32.dll 	BaseProcessStart 	

More reports at:
http://crash-stats.mozilla.com/report/list?range_value=4&range_unit=week&signature=send&version=Firefox%3A4.0b8pre

Comment 1

[(no longer active)]

This is now the 2nd topcrasher in windows.

I looked at the stacks for many crashes under this signature.  In everycase, it seems like us calling the send Winsock function takes us to somewhere inside vksaver.dll, which would lead to an ultimate crash shortly (either on the same frame or some more frames down the stack).

Now, as far as I know, the only way that this could happen is for vksaver.dll to hook the send API and cause us to execute its code.

This looks *very* bad.  Should we blocklist this DLL (or something)?

Comment 2

[Boris Zbarsky [:bzbarsky]]

If my searching is not lying to me, it's somewhat common for viruses to masquerade as this DLL.  So yes, I think we should consider blocklisting.

Comment 3

[Scoobidiver (away)]

In reply to comment 1
> This is now the 2nd topcrasher in windows.
Behind the send crash signature, there are a lot of stack traces, the one with vksaver is only one among others.

In reply to comment 2
> it's somewhat common for viruses to masquerade as this DLL
vksaver is a very common peer-or-peer software in Russia:
http://audiovkontakte.ru/
From Google translate:
"This program allows you to download audio and video from the contact easy and fast way. In this case, it is absolutely free!"
The current version is 2.2.2.0 so block-listing it will make Russian users angry.

Comment 4

[Scoobidiver (away)]

It shows up as #12 top crasher in 4.0b12pre over the last week because of a lot of consecutive startup crashes.
It is #139 top crasher in 4.0b11 over the last week.

Comment 5

[(not currently active) Ted Mielczarek]

Presumably it could be installed as an LSP, but I don't see it in our reported LSP info (looking at the raw JSON).

Comment 6

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

It's possible that we're not grabbing all the categories we need to ...

I agree with the assessment in comment 1 that it looks like vksaver is hooking some windows functions that we're trying to use.  If this were working as an LSP we'd expect to see some windows stuff on the stack between _PR_MD_SEND and vksaver.  There are also a bunch of crashes on Vista and 7, where we're effectively blocking most LSPs.

I'd also suggest blocklisting.  We're already blocklisting an older version of this.

Comment 7

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

The bug where we blocklisted this last time was Bug 540692.

Comment 8

[timeless]

fwiw, i wouldn't expect to see windows stuff past _PR_MD_SEND, because we generally don't. it might also relate to how tail call optimizations work, not quite sure.

Comment 9

[Scoobidiver (away)]

There are other crash signatures with vksaver.dll:
vksaver.dll@0x3398, vksaver.dll@0x3392, vksaver.dll@0x4917
With the 4 combined crash signatures, it is a virtual #10 top crasher in 4.0b11 over the last week.

What will be the effect of block-listing the current version of vksaver on vksaver users?
It would be good to contact the author before any action: audiovkontakte.ru [at]
gmail.com.

Comment 10

[Alexander L. Slovesnik]

CC'ing vksaver developer.

Comment 11

[(no longer active)]

(In reply to comment #4)
> It shows up as #12 top crasher in 4.0b12pre over the last week because of a lot
> of consecutive startup crashes.
> It is #139 top crasher in 4.0b11 over the last week.

It is actually the 4th topcrasher under the [@ send] signature.

Comment 12

[Benjamin Smedberg]

It isn't really possible to get good topcrash rating from nightlies: the sample population is too small, and it's very easy to skew the statistics while working on/testing a bug.

send is #130 in b11, vksaver is #34 and #35 and a few others. I don't think this blocks, although I think we should be more aggresive about blocklisting.

Comment 13

[Scoobidiver (away)]

As this bug is no longer a Firefox bug but a vksaver one (Blocklisting component), I added all vksaver signatures to the bug summary.

It is a virtual #10 top crasher in 4.0b11 (see comment 9) and #3 top crasher in 3.6.13, so it should block.
Simultaneously, vksaver developers should work to fix these crashes in a future version.

Comment 14

[Benjamin Smedberg]

#10 is not enough to block at this point.

Should we add vksaver.dll up through 2.2.2.0 to the DLL blocklist? That's the only version I really see in reports.

Comment 15

[Johnathan Nightingale [:johnath]]

(In reply to comment #14)

> Should we add vksaver.dll up through 2.2.2.0 to the DLL blocklist? That's the
> only version I really see in reports.

One of the reasons I'm keen to see what we can accomplish through having Kev reach out to vkontakte is that we've DLL blocked vksaver already, on an older version:

http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsWindowsDllBlocklist.h#105

Comment 16

[Scoobidiver (away)]

> That's the only version I really see in reports.
There are currently 3 vksaver versions:
 0% (0/125) vs.   0% (10/46796) 1.0.0.1 (someone by-passed the current blocklisting introduced by bug 540692)
 2% (3/125) vs.   0% (13/46796) 2.2.1.0
98% (122/125) vs.   1% (404/46796) 2.2.2.0

Blocklisting vksaver will impact 0.9% of all Fx4 users.
As Russian represents 3% of Firefox 4.0b11 (see http://input.mozilla.com/en-US/beta/search?q=&product=firefox&version=4.0b11&date_start=&date_end=), it will impact 30% of Russian Fx4 users.

Comment 17

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #16)
> Blocklisting vksaver will impact 0.9% of all Fx4 users.
> As Russian represents 3% of Firefox 4.0b11 (see
> http://input.mozilla.com/en-US/beta/search?q=&product=firefox&version=4.0b11&date_start=&date_end=),
> it will impact 30% of Russian Fx4 users.

That's incorrect.  If an addon is causing lots of crashes, it will show up in a much larger proportion of crash reports than its true prevalence among users.

Comment 18

[Scoobidiver (away)]

> That's incorrect.
Stats I gave in comment 16 are based on the second column, that is the proportion of all crashes (not only the ones with vksaver signature) that have the vksaver.dll module loaded.
So they are right, assuming that each ADU has the same crash rate.

Comment 19

[(no longer active)]

(In reply to comment #15)
> (In reply to comment #14)
> 
> > Should we add vksaver.dll up through 2.2.2.0 to the DLL blocklist? That's the
> > only version I really see in reports.
> 
> One of the reasons I'm keen to see what we can accomplish through having Kev
> reach out to vkontakte is that we've DLL blocked vksaver already, on an older
> version:
> 
> http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsWindowsDllBlocklist.h#105

And I think we should blocklist up to 2.2.2.0.  Whether or not we get a response from vkontakte would only affect whether future versions of vksaver will have this bug.  It won't affect all of the users who are crashing because of the bugs in the current versions.

Comment 20

[(no longer active)]

Attachment: Blocklist vksaver.dll up to 2.2.2.0

Comment 21

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #18)
> > That's incorrect.
> Stats I gave in comment 16 are based on the second column, that is the
> proportion of all crashes (not only the ones with vksaver signature) that have
> the vksaver.dll module loaded.
> So they are right, assuming that each ADU has the same crash rate.

Which is a totally incorrect assumption when some of the users have extensions that cause lots of crashes and some don't.

Comment 22

[Benjamin Smedberg]

Comment on attachment 512863 [details] [diff] [review]
Blocklist vksaver.dll up to 2.2.2.0

Yes, we should do this.

Comment 23

[(no longer active)]

Comment on attachment 512863 [details] [diff] [review]
Blocklist vksaver.dll up to 2.2.2.0

I can't request approval2.0 on this.  Can this land on trunk?

Comment 24

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 512863 [details] [diff] [review]
Blocklist vksaver.dll up to 2.2.2.0

a2.0=dbaron

Comment 25

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/1249116e394c

Comment 26

[Daniel Veditz [:dveditz]]

Not blocking, but good to take.

Comment 27

[Daniel Veditz [:dveditz]]

Comment on attachment 512863 [details] [diff] [review]
Blocklist vksaver.dll up to 2.2.2.0

approved for 1.9.2.15, a=dveditz for release-drivers

Comment 28

[Scoobidiver (away)]

Crashes still happen with vksaver dlls without version. See:
bp-a8bbe3aa-3e16-4cf2-bb4b-fccf32110219

Comment 29

[(no longer active)]

(In reply to comment #28)
> Crashes still happen with vksaver dlls without version. See:
> bp-a8bbe3aa-3e16-4cf2-bb4b-fccf32110219

Hmm, the DLL blocklist code should block DLLs which do not have version information.  Am I missing something, Vlad?

Comment 30

[Scoobidiver (away)]

There is also a vksaver version 2.2.2.0 in crash reports:
bp-1bb797b2-6a35-4e90-9d49-ad54f2110220
That means some people clicked on the "Start later" button.

Comment 31

[(no longer active)]

(In reply to comment #30)
> There is also a vksaver version 2.2.2.0 in crash reports:
> bp-1bb797b2-6a35-4e90-9d49-ad54f2110220
> That means some people clicked on the "Start later" button.

The "Start later" button?

Comment 32

[Scoobidiver (away)]

> The "Start later" button?
I was talking about bug 523784 that replaced the Cancel button by this button in the add-ons-may-be-causing-problems dialog box, but I was wrong, the DLL has probably been unchecked in this dialog box.

Comment 33

[Robert Strong (they/them - no direct email)]

(In reply to comment #32)
This blocking of specific dll's which this bug is about is hardcoded in toolkit/xre/nsWindowsDllBlocklist.h and the blocklisting referenced in bug 523784 is for add-ons so bug 523784 isn't involved.

Comment 34

[Scoobidiver (away)]

The add-ons blocklisting is referenced in http://www.mozilla.com/en-US/blocklist/.
Where is the DLL blocklisting referenced?

Comment 35

[Robert Strong (they/them - no direct email)]

(In reply to comment #34)
> The add-ons blocklisting is referenced in
> http://www.mozilla.com/en-US/blocklist/.
> Where is the DLL blocklisting referenced?

You can see the file in the checkin
(In reply to comment #25)
> http://hg.mozilla.org/mozilla-central/rev/1249116e394c

and here is the entire file
http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsWindowsDllBlocklist.h

Comment 36

[Robert Strong (they/them - no direct email)]

(In reply to comment #29)
> (In reply to comment #28)
> > Crashes still happen with vksaver dlls without version. See:
> > bp-a8bbe3aa-3e16-4cf2-bb4b-fccf32110219
> 
> Hmm, the DLL blocklist code should block DLLs which do not have version
> information.  Am I missing something, Vlad?
It should catch the normal case where the dll is loaded via loadlibrary (we replace it) but there are other ways of getting around it such as file mapping.

Comment 37

[Scoobidiver (away)]

In reply to comment 35
> and here is the entire file
Should the DLL blocklisting be made public for Firefox users and not only for developers for at least non-malware softwares as vksaver is?

Comment 38

[Robert Strong (they/them - no direct email)]

You mean a public facing web page similar to the blocklisting website... perhaps.

cc'ing LegNeato and johnath is already cc'd

Comment 39

[Scoobidiver (away)]

> You mean a public facing web page similar to the blocklisting website...
Yes. You just need to add a software section (for DLL) to the current blocklisting website.

Comment 40

[Johnathan Nightingale [:johnath]]

I'd say the website content there is morgamic's call. Personally, I don't feel strongly either way - could put it there for completeness, but so few users actually know what a DLL is, much less why we might block some of them, that it seems to me to be of limited benefit. I agree that the vksaver case here falls into a grey area, though.

Comment 41

[Justin Scott [:fligtar]]

That blocklist page is moving to AMO this quarter so that it can be dynamic, so if DLLs are to be added on the same page, AMO will need to add a table for them or manually push updates, which I'd rather not do.

AFAIK there is no user-facing "Learn more" link that someone would click to see blocked DLLs, so I think a wiki page would suffice for this. We can link to it from the Blocklist policy page that's currently being revamped.

Comment 42

[(no longer active)]

(In reply to comment #36)
> (In reply to comment #29)
> > (In reply to comment #28)
> > > Crashes still happen with vksaver dlls without version. See:
> > > bp-a8bbe3aa-3e16-4cf2-bb4b-fccf32110219
> > 
> > Hmm, the DLL blocklist code should block DLLs which do not have version
> > information.  Am I missing something, Vlad?
> It should catch the normal case where the dll is loaded via loadlibrary (we
> replace it) but there are other ways of getting around it such as file mapping.

Can you provide more details?  Note that we're hooking LdrLoadLibary, which should catch any method of loading the DLL as an executable module...

Comment 43

[Robert Strong (they/them - no direct email)]

My statement was from a brief discussion with Vlad and since he understands the cases much better than I do I'll leave the question to him

Comment 44

[(no longer active)]

(In reply to comment #43)
> My statement was from a brief discussion with Vlad and since he understands the
> cases much better than I do I'll leave the question to him

OK.  Vlad, can you please elaborate?

Comment 45

[(no longer active)]

Actually I see vksaver.dll 2.2.2.0 in a lot of crash reports from b12, so it seems like the blocklist has not been effective for some reason...

Comment 46

[Scoobidiver (away)]

> so it seems like the blocklist has not been effective for some reason...
With the blocklisting and combined signatures, it is #5 top crasher in 4.0b12.

Comment 47

[Benjamin Smedberg]

Ehsan, can you link me to them? All the reports I've loaded have had a vksaver with no version field.

Comment 48

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

bp-fffff8df-ebc3-410d-87cb-19c472110302
bp-fff2ed26-4ac3-43c3-91d8-dcb5d2110302
bp-d148680f-74e0-4baf-8109-745d92110302

Comment 49

[(no longer active)]

I think we now have enough evidence to know that vksaver.dll is not loaded using the common DLL loading mechanisms.

Is there any way for a developer to install this software and test its loading method?

Comment 50

[Alexander L. Slovesnik]

(In reply to comment #49)
> I think we now have enough evidence to know that vksaver.dll is not loaded
> using the common DLL loading mechanisms.
> 
> Is there any way for a developer to install this software and test its loading
> method?
http://audiovkontakte.ru/vksaver/vksaver-install-2.2.2.exe is link to latest version.

Comment 51

[(no longer active)]

(In reply to comment #50)
> (In reply to comment #49)
> > I think we now have enough evidence to know that vksaver.dll is not loaded
> > using the common DLL loading mechanisms.
> > 
> > Is there any way for a developer to install this software and test its loading
> > method?
> http://audiovkontakte.ru/vksaver/vksaver-install-2.2.2.exe is link to latest
> version.

I'll take a look at this next week when I have access to a useful Windows machine.  Thanks a lot for the link.

Comment 52

[chris hofmann]

Attachment: unversioned .dlls in sample of [@ send] crash reports

I'm not sure of the exact connection or the direction of the possible correlation flow but RocketDock.dll and other unversioned .dlls show up in the module list of crash reports with this signature on occasion just like they do in a variety of other possible malware signatures.

Comment 53

[chris hofmann]

> other possible malware signatures

see attachment in Bug 633445 - Crash [@ mozalloc_abort(char const* const)

Comment 54

[(no longer active)]

This is interesting.  Whatever is going on here might also have some correlation to bug 633445.

Comment 55

[(no longer active)]

So, I installed vksaver locally and investigated, and here is the results of the investigation.

Firstly, the blocklist entry is completely ineffective.  vksaver adds an entry to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs, which causes user32.dll's DllMain to load vksaver.dll for every process on the system, and this happens way before main, so our blocklist code doesn't really have any chance of catching that in its current form.

Also, it installed an add-on with the ID [e-mail] which is not marked as compatible with Firefox 4 (and will only get enabled if you've overridden the compatibility).

I've been using the system for a few hours with vksaver installed, and it doesn't seem to be very unstable (i.e., I haven't seen a crash in any program in the system so far).

So, here's a theory.  Maybe it's the interaction of the add-on and vksaver.dll which is causing the crashes, and the mere fact that vksaver.dll gets loaded into our address space doesn't have any significance.  If that is the case, we can just blocklist the add-on and ignore the DLL.

In order to verify this theory, I need some information.  Basically, I need a query to be run on all of the crashstats reports which have vksaver.dll in their signature to see a) whether they have an add-on with ID [e-mail] installed, and b) whether they have EMCheckCompatibility set to False.  If the result of this query is "true", then we can experiment with blocklisting this add-on and see if it causes the crash to trend down.

chofmann, can you let me know how I can run such a query please?  Thanks!

Comment 56

[Alex Pakhotin (:alexp)]

(In reply to comment #55)
> Firstly, the blocklist entry is completely ineffective.  vksaver adds an entry
> to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows
> NT\CurrentVersion\Windows\AppInit_DLLs, which causes user32.dll's DllMain to
> load vksaver.dll for every process on the system, and this happens way before
> main, so our blocklist code doesn't really have any chance of catching that in
> its current form.

I actually expressed my concern about this in the comments to the bug 540692, but was assured we could block it.

> Also, it installed an add-on with the ID [e-mail] which is not marked
> as compatible with Firefox 4 (and will only get enabled if you've overridden
> the compatibility).

Again, as I mentioned in my comment to the bug 540692, this Yandex add-on is optional, and is not related to VKSaver at all. It's just the way of distribution, similar to how Google Toolbar is distributed as an optional addition to some 3rd-party freeware apps. I'm pretty sure VKSaver does not interact with this add-on.

> I've been using the system for a few hours with vksaver installed, and it
> doesn't seem to be very unstable (i.e., I haven't seen a crash in any program
> in the system so far).

As far as I understand, the crashes happen when the users try to open vkontakte.ru - the site, which this VKSaver is supposed to handle. When any browser opens that site, this program does some hacking on a low-level, and apparently does that not quite correct way, which causes Firefox to crash.

I tried to open vkontakte.ru with VKSaver installed, and didn't get a crash. Maybe one needs to login to that site, I couldn't test that as I don't have an account there.

As far as I understand the CC'd [e-mail] is the VKSaver author's email. Can the author provide his comments on this issue please?

Comment 57

[chris hofmann]

(In reply to comment #55)
> 
> chofmann, can you let me know how I can run such a query please?  Thanks!

some simple screen scrapping is the quickest way to get some initial data.  If we think its worthwhile to probe deeper we can request a map reduce job from the socorro team.

I looked at sample of 100 reports that had a variety of vksaver.dll signatures.  

89% had addon compat checking turned on.  11% unknown
54% had yandex.ru loaded, 46% didn't

one particular signature "vksaver.dll@0x3064" had no instances of [e-mail]

the rest of the signatures had a mixed bag.

I'll attach the raw data for a closer look shortly.

Comment 58

[chris hofmann]

Attachment: signature,crash-report-link,fxversion,add-compat-check-status,vksaver-version-info,yandex-search-installed-status

Comment 59

[Alex Pakhotin (:alexp)]

(In reply to comment #57)
> 54% had yandex.ru loaded, 46% didn't

Oh, can we tell, which sites were open at the moment of the crash?
Is it possible to check if vkontakte.ru was in that list?

Comment 60

[chris hofmann]

yeah, running another report overnight to get the url data, and bump the sample size to 500.

an early look at that data shows that indeed http://vkontakte.ru is loaded a pretty high pct of the time.  other reports have no urls, or this short list.

http://ru.wikipedia.org/wiki/%D0%91%D1%80%D0%BE%D0%BA,_%D0%A3%D0%B8%D0%BB%D1%8C%D1%8F%D0%BC vksaver.dll 

http://www.lastfm.ru/listen/artist/The%2BRolling%2BStones/similarartists

http://lice-mer.ru/feed/

Comment 61

[chris hofmann]

> Maybe one needs to login to that site, I couldn't test that as I don't have 
> an account there.

yes, it does look like the urls reflect some kind of login or session id info, so I think accounts are needed to test.  here is a sample of the areas of the site where the crashes happen

  19 vkontakte.ru audio.php?id
  14 vkontakte.ru LOGIN_ID#
  14 vkontakte.ru al_profile.php?__query
  14 vkontakte.ru al_audio.php?__query
  10 vkontakte.ru al_video.php?__query
   4 vkontakte.ru audio
   4 vkontakte.ru 
   3 www.vkontakte.ru 
   3 vkontakte.ru search?c[section]
   3 vkontakte.ru groups.php
   3 vkontakte.ru audio.php?album_id
   3 vkontakte.ru apps.php
   3 vk.com al_video.php?__query
   3 a.adwolf.ru getCode?p3
   2 www.lastfm.ru listen
   2 vkontakte.ru notes.php
   2 vkontakte.ru mail#
   2 vkontakte.ru audio.php?gid
   2 vkontakte.ru audio#
   2 vkontakte.ru apps.php?mid
   2 vkontakte.ru al_mail.php?__query
   2 nibera.ru electronic
   2 audiovkontakte.ru download.php?type
   1 www.rusfootball.info 
   1 www.google.ru search?q
   1 www.avast.com go.php?verb

Comment 62

[Alexander L. Slovesnik]

(In reply to comment #61)
> yes, it does look like the urls reflect some kind of login or session id info,
> so I think accounts are needed to test.
For registration in Russian version of Vkontakte - http://vkontakte.ru you need to be invited. I have 3 invites, you can mail me your phone number if you need invite.
Dunno about English version of Vkontakte - http://vk.com

Comment 63

[chris hofmann]

here is the data from a larger sample of 500 reports.

 110 vksaver.dll@0x3398 <td>[e-mail]</td>
  93 vksaver.dll@0x3398 no yasearch

 110 vksaver.dll@0x3392 <td>[e-mail]</td>
  87 vksaver.dll@0x3392 no yasearch

  37 vksaver.dll@0x4917 <td>[e-mail]</td>
  22 vksaver.dll@0x4917 no yasearch

  33 vksaver.dll@0x3064 no yasearch

   1 vksaver.dll@0x4868 <td>[e-mail]</td>

   1 vksaver.dll@0x4d99 <td>[e-mail]</td>

   1 vksaver.dll@0x3e06 <td>[e-mail]</td>

   2 vksaver.dll@0x2fc4 no yasearch
 
   1 vksaver.dll@0x4868 no yasearch

   1 vksaver.dll@0x5d10 no yasearch

   1 vksaver.dll@0x5920 no yasearch

about 438 of 500 reports had addon compat checked, and the rest had no status ( a possible indication of a start up crashes before addon checking status is set up).

almost 4 out of 5 had a vkontakte url, and the rest had no url or another russian site loaded.  only 3 reports didn't follow this pattern.

 369 vkontakte.ru
   9 vk.com
   4 audiovkontakte.ru
   3 www.vkontakte.ru

  82 [no url set]

  11 a.adwolf.ru

   2 www.lastfm.ru
   2 www.google.ru
   2 nibera.ru
   1 www.yandex.ru
   1 www.rusfootball.info
   1 www.odnoklassniki.ru
   1 www.avast.com
   1 win.mail.ru
   1 ru12.voyna-plemyon.ru
   1 ru.wikipedia.org
   1 my.mail.ru
   1 maps.google.ru
   1 loveplanet.ru
   1 lice-mer.ru
   1 gladwars.ru

   1 www.erepublik.com
   1 www.beatport.com
   1 download.skype.com

Comment 64

[(no longer active)]

(In reply to comment #62)
> (In reply to comment #61)
> > yes, it does look like the urls reflect some kind of login or session id info,
> > so I think accounts are needed to test.
> For registration in Russian version of Vkontakte - http://vkontakte.ru you need
> to be invited. I have 3 invites, you can mail me your phone number if you need
> invite.

Could you let me use one of these invites, please?  What do they use the phone number for?  Just texting a confirmation code or something similar?

Comment 65

[(no longer active)]

(In reply to comment #63)
> about 438 of 500 reports had addon compat checked, and the rest had no status (
> a possible indication of a start up crashes before addon checking status is set
> up).

Can we look at the uptime for the latter group?

I think this data and comment 56 show that the add-on may be irrelevant here.

> almost 4 out of 5 had a vkontakte url, and the rest had no url or another
> russian site loaded.  only 3 reports didn't follow this pattern.

I'll try to reproduce this crash, to see if there is anything that we can do about it without blacklisting vksaver.dll.

If that proves unsuccessful, we should start looking into ways to blacklist DLLs loaded through AppInit_DLLs.

Comment 66

[timeless]

so, with some effort we could make firefox.exe not link to user32.dll (instead delegating that to xul.dll), that'd enable our blocklist to handle appinit things too.

Comment 67

[(no longer active)]

(In reply to comment #66)
> so, with some effort we could make firefox.exe not link to user32.dll (instead
> delegating that to xul.dll), that'd enable our blocklist to handle appinit
> things too.

Hmm, good idea.  Do you have any idea how to approach it, though?  I'm not really sure what exact source files constitute the code which ends up in firefox.exe...

Comment 68

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

To a rough first approximation, anything in tier_app for Firefox.

Comment 69

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Actually, that's wrong (I forgot about browsercomps.dll).

nsBrowserApp.cpp and possibly some static libs from elsewhere.

Comment 70

[(no longer active)]

(In reply to comment #69)
> Actually, that's wrong (I forgot about browsercomps.dll).
> 
> nsBrowserApp.cpp and possibly some static libs from elsewhere.

The former is obvious, I'm more interested in the latter!  ;-)

Is there any way to get the exact information from the build system?

Comment 71

[timeless]

1. delete firefox.exe
2. do an incremental build.
3. the linker line will appear.
4. delete all the .lib's it lists
5. goto 2

Comment 72

[(no longer active)]

I've been trying to see if I can trap anything suspicious under the debugger using vkontakte.ru on a system with vksaver.dll installed.  I've managed to get this error multiple times:

"Received "nonqueued" message 49466 during a synchronous IPC message for window 461204 ("MozillaWindowClass"), sending it to DefWindowProc instead of the normal window procedure."

with this stack:


 	xul.dll!RealBreak()  Line 421	C++
 	xul.dll!Break(const char * aMsg=0x001fbf54)  Line 525	C++
>	xul.dll!NS_DebugBreak_P(unsigned int aSeverity=0x00000001, const char * aStr=0x108d0e08, const char * aExpr=0x5bd5cb5c, const char * aFile=0x5bd5cb28, int aLine=0x0000013f)  Line 385 + 0xc bytes	C++
 	xul.dll!`anonymous namespace'::ProcessOrDeferMessage(HWND__ * hwnd=0x00070994, unsigned int uMsg=0x0000c13a, unsigned int wParam=0x00000000, long lParam=0x00000000)  Line 319 + 0x1f bytes	C++
 	xul.dll!NeuteredWindowProc(HWND__ * hwnd=0x00070994, unsigned int uMsg=0x0000c13a, unsigned int wParam=0x00000000, long lParam=0x00000000)  Line 356 + 0x15 bytes	C++
 	user32.dll!_InternalCallWinProc@20()  + 0x23 bytes	
 	user32.dll!_UserCallWinProcCheckWow@32()  + 0xb7 bytes	
 	user32.dll!_DispatchClientMessage@24()  + 0x51 bytes	
 	user32.dll!___fnDWORD@4()  + 0x2b bytes	
 	ntdll.dll!_KiUserCallbackDispatcher@12()  + 0x2e bytes	
 	user32.dll!_NtUserPeekMessage@20()  + 0x15 bytes	
 	user32.dll!__PeekMessage@24()  + 0x2d bytes	
 	user32.dll!_PeekMessageW@20()  + 0x197 bytes	
 	xul.dll!mozilla::ipc::RPCChannel::WaitForNotify()  Line 917 + 0x12 bytes	C++
 	xul.dll!mozilla::ipc::RPCChannel::Call(IPC::Message * msg=0x0b4bf1c0, IPC::Message * reply=0x001fcac0)  Line 201 + 0xb bytes	C++
 	xul.dll!mozilla::plugins::PPluginScriptableObjectParent::CallHasProperty(mozilla::plugins::PPluginIdentifierParent * aId=0x0b91c8d0, bool * aHasProperty=0x001fcb3b)  Line 288 + 0x16 bytes	C++
 	xul.dll!mozilla::plugins::PluginScriptableObjectParent::ScriptableHasProperty(NPObject * aObject=0x054268e0, void * aName=0x05823a60)  Line 312 + 0x17 bytes	C++
 	xul.dll!NPObjWrapper_NewResolve(JSContext * cx=0x10c59818, JSObject * obj=0x0d83b078, jsid id={...}, unsigned int flags=0x00000005, JSObject * * objp=0x001fcbbc)  Line 1648 + 0x12 bytes	C++
 	mozjs.dll!CallResolveOp(JSContext * cx=0x10c59818, JSObject * start=0x0db280a8, JSObject * obj=0x0d83b078, jsid id={...}, unsigned int flags=0x00000005, JSObject * * objp=0x001fcc74, JSProperty * * propp=0x001fcc68, bool * recursedp=0x001fcc13)  Line 4898 + 0x17 bytes	C++
 	mozjs.dll!js_LookupPropertyWithFlagsInline(JSContext * cx=0x10c59818, JSObject * obj=0x0d83b078, jsid id={...}, unsigned int flags=0x0000ffff, JSObject * * objp=0x001fcc74, JSProperty * * propp=0x001fcc68)  Line 4971 + 0x25 bytes	C++
 	mozjs.dll!js_GetPropertyHelperWithShapeInline(JSContext * cx=0x10c59818, JSObject * obj=0x0db280a8, JSObject * receiver=0x0db280a8, jsid id={...}, unsigned int getHow=0x00000001, js::Value * vp=0x001fcd1c, const js::Shape * * shapeOut=0x001fcca0, JSObject * * holderOut=0x001fcca4)  Line 5354 + 0x23 bytes	C++
 	mozjs.dll!js_GetPropertyHelperInline(JSContext * cx=0x10c59818, JSObject * obj=0x0db280a8, JSObject * receiver=0x0db280a8, jsid id={...}, unsigned int getHow=0x00000001, js::Value * vp=0x001fcd1c)  Line 5457 + 0x25 bytes	C++
 	mozjs.dll!js_GetPropertyHelper(JSContext * cx=0x10c59818, JSObject * obj=0x0db280a8, jsid id={...}, unsigned int getHow=0x00000001, js::Value * vp=0x001fcd1c)  Line 5463 + 0x1d bytes	C++
 	mozjs.dll!InlineGetProp(js::VMFrame & f={...})  Line 1890 + 0x40 bytes	C++
 	mozjs.dll!js::mjit::stubs::GetProp(js::VMFrame & f={...})  Line 1902 + 0x8 bytes	C++
 	mozjs.dll!DisabledGetPropIC(js::VMFrame & f={...}, js::mjit::ic::PICInfo * pic=0x104dbef0)  Line 1625	C++
 	05a54029()	
 	xul.dll!nsJSContext::CallEventHandler(nsISupports * aTarget=0x0e724968, void * aScope=0x0d826370, void * aHandler=0x0d8c0f88, nsIArray * aargv=0x1153b9dc, nsIVariant * * arv=0x001fd148)  Line 1914 + 0x2e bytes	C++
 	xul.dll!nsGlobalWindow::RunTimeout(nsTimeout * aTimeout=0x0c169e90)  Line 9107 + 0xb1 bytes	C++
 	xul.dll!nsGlobalWindow::TimerCallback(nsITimer * aTimer=0x094da0e8, void * aClosure=0x0c169e90)  Line 9455	C++
 	xul.dll!nsTimerImpl::Fire()  Line 425 + 0xe bytes	C++
 	xul.dll!nsTimerEvent::Run()  Line 519	C++
 	xul.dll!nsThread::ProcessNextEvent(int mayWait=0x00000000, int * result=0x001fd37c)  Line 633 + 0x19 bytes	C++
 	xul.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x00d14dd8, int mayWait=0x00000000)  Line 250 + 0x16 bytes	C++
 	xul.dll!mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate * aDelegate=0x00d113b8)  Line 110 + 0xe bytes	C++
 	xul.dll!MessageLoop::RunInternal()  Line 220	C++
 	xul.dll!MessageLoop::RunHandler()  Line 203	C++
 	xul.dll!MessageLoop::Run()  Line 177	C++
 	xul.dll!nsBaseAppShell::Run()  Line 198	C++
 	xul.dll!nsAppShell::Run()  Line 264 + 0x9 bytes	C++
 	xul.dll!nsAppStartup::Run()  Line 220 + 0x1c bytes	C++
 	xul.dll!XRE_main(int argc=0x00000001, char * * argv=0x0041def0, const nsXREAppData * aAppData=0x0041df80)  Line 3786 + 0x25 bytes	C++
 	firefox.exe!NS_internal_main(int argc=0x00000001, char * * argv=0x0041def0)  Line 158 + 0x12 bytes	C++
 	firefox.exe!wmain(int argc=0x00000001, wchar_t * * argv=0x00419e50)  Line 128 + 0xd bytes	C++
 	firefox.exe!__tmainCRTStartup()  Line 579 + 0x19 bytes	C
 	firefox.exe!wmainCRTStartup()  Line 399	C
 	kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 bytes	
 	ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes	
 	ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes	

The message code is 0x0000c13a, lparam and wparam are both 0, and the window handle is that of a hidden window with class MozillaWindowClass, belonging to the firefox.exe process.

Is that something which could lead to a crash in optimized builds?

Comment 73

[Jim Mathies [:jimm]]

That's a message generated by RegisterWindowMessage, which we use in a few places. Might be interesting to see which one it is.

Comment 74

[(no longer active)]

Attachment: Enable blocking DLLs loaded via AppInit_Dlls

OK, I finally have a patch which enables making the AppInit_DLLs entries subject to our blocklist too.

The trick of making firefox.exe not load user32.dll wouldn't work, since we have a bunch of other DLLs which link against user32.dll statically, which would trigger loading user32.dll before main is run anyways.

So, I thought about the possibility of delay-loading user32.dll, so that we get a chance to run code before that DLL is loaded into our process.  I finally made it work.  Here is how the patch works:

Firstly, we need a list of DLLs which links against user32.dll statically (either directly or indirectly).  These DLLs are xul.dll, xpcom.dll, nspr4.dll, and plc4.dll.  I made firefox.exe delay load these DLLs in addition to user32.dll itself.  This is done in browser/app/Makefile.in.

Then I hacked wmain to call SetupDllBlocklist as its first thing to do, since mozilla::NS_SetDllDirectory comes from xpcom.dll, and calling it would cause user32.dll to be loaded, and we lose.

Another tricky bit was patched_LdrLoadDll calling NS_SetHasLoadedNewDLLs, which comes from xpcom.dll as well.  This would cause a recursive load of xul.dll at startup, which would lead into stack exhaustion at startup.  To solve this problem, I made calling that function conditional on the value of a variable called isDelayLoading.  And in wmain, before calling any function which would trigger loading xul.dll dynamically, I used the VC-specific function __HrLoadAllImportsForDll to force-load all of our delay-loaded DLLs, and then set isDelayLoading to false so that future invocations of this patched_LdrLoadDll would also include the call to NS_SetHasLoadedNewDLLs.

I've tested this patch, and with this, we successfully block vksaver.dll version 2.2.2.0 from loading.

I think we'd want to take this on mozilla-central as soon as the tree reopens, but unfortunately there is no low-risk fix for the 2.0 branch as far as my research shows.

Comment 75

[(no longer active)]

(In reply to comment #73)
> That's a message generated by RegisterWindowMessage, which we use in a few
> places. Might be interesting to see which one it is.

Well, that relieves me, as it shows that it's not something which is done by vksaver.dll.

Comment 76

[(no longer active)]

Attachment: Enable blocking DLLs loaded via AppInit_Dlls

This patch fixes a compilation problem for plugin-container.exe in the previous patch.

Comment 77

[Benjamin Smedberg]

Comment on attachment 519434 [details] [diff] [review]
Enable blocking DLLs loaded via AppInit_Dlls

At this point, I don't think the code complexity and risk of delay-loading is worth the benefit of blocking malware which has already made it into the windows registry.

Comment 78

[(no longer active)]

(In reply to comment #77)
> Comment on attachment 519434 [details] [diff] [review]
>   --> https://bugzilla.mozilla.org/attachment.cgi?id=519434
> Enable blocking DLLs loaded via AppInit_Dlls
> 
> At this point, I don't think the code complexity and risk of delay-loading is
> worth the benefit of blocking malware which has already made it into the
> windows registry.

So, should we WONTFIX this bug?

Comment 79

[Alexander L. Slovesnik]

(In reply to comment #78)
> So, should we WONTFIX this bug?
WONTFIXing this bug will leave users in cold. At least they should be warned about well-known AppInit badware/malware loaded along with Firefox.
Perhaps different approach could work. Can Firefox detect on startup through registry check that well-known AppInit badware/malware is loaded along Firefox and present user with proposal to remove badware/malware from registry and restart his computer? Or open support.mozilla.org article with info on removing badware/malware from computer?

P.S. I wonder if third-party .dll, loaded with Firefox, should be listed in Addon Manager. They are not much different from common plugins from user's point of view.

Comment 80

[Scoobidiver (away)]

> Or open support.mozilla.org article with info on removing badware/malware from 
> computer?
http://support.mozilla.com/kb/Is%20my%20Firefox%20problem%20a%20result%20of%20malware

Comment 81

[(no longer active)]

(In reply to comment #79)
> (In reply to comment #78)
> > So, should we WONTFIX this bug?
> WONTFIXing this bug will leave users in cold. At least they should be warned
> about well-known AppInit badware/malware loaded along with Firefox.

I don't think we'd want to have such warnings.  Firefox is not a malware detection tool!

> Perhaps different approach could work. Can Firefox detect on startup through
> registry check that well-known AppInit badware/malware is loaded along Firefox
> and present user with proposal to remove badware/malware from registry and
> restart his computer?

It can, but like I said, I don't think that we should.  Maybe this information can be stored as a SUMO article though.

> P.S. I wonder if third-party .dll, loaded with Firefox, should be listed in
> Addon Manager. They are not much different from common plugins from user's
> point of view.

vksaver.dll is not an add-on, so I don't see why it should be listed in the Add-on Manager.

Comment 82

[(no longer active)]

Another approach is for us to move this over to Evangelism to see if we can contact the vendor and ask them to look into the issue?

vksaver.dll also seems to be hooking into IE, Chrome and Opera.  It would be interesting if we can see if those browsers are experiencing similar crash problems.

Comment 83

[Alex Pakhotin (:alexp)]

(In reply to comment #82)
> Another approach is for us to move this over to Evangelism to see if we can
> contact the vendor and ask them to look into the issue?

I think this actually would be the best. But even though the author of that DLL is already CC'd on this bug, he never replied in the comments.

vksaver.dll is not a malware, it's actually intended to help users, similar to the add-ons. It is just implemented some non-standard way to handle any browser, but turns out, this way is not quite compatible with Firefox. As far as I understand, this might be version-specific, as when such crashes occurred before, the update to the DLL fixed the problem.

Comment 84

[Bill Gianopoulos [:WG9s]]

Can't this be blocklisted somehow?

Comment 85

[Alexander L. Slovesnik]

(In reply to comment #81)
> (In reply to comment #79)
> > (In reply to comment #78)
> > > So, should we WONTFIX this bug?
> > WONTFIXing this bug will leave users in cold. At least they should be warned
> > about well-known AppInit badware/malware loaded along with Firefox.
> 
> I don't think we'd want to have such warnings.  Firefox is not a malware
> detection tool!
The whole point of Firefox dll blocklist is to detect problematic dll's, not catched by existing antivirus tools. Vksaver is not a malware, it's not intended to harm user's computer, its signature is not present in any antivirus bases, so a user can not rely on antivirus/malware detection tools to troubleshoot problem with vksaver.
 
> > P.S. I wonder if third-party .dll, loaded with Firefox, should be listed in
> > Addon Manager. They are not much different from common plugins from user's
> > point of view.
> 
> vksaver.dll is not an add-on, so I don't see why it should be listed in the
> Add-on Manager.
For example to make user support easier. Right now it's hard to detect if user's problem caused by third-party dll. Is it possible at least add list of these dll to about:support?

Comment 86

[Bill Gianopoulos [:WG9s]]

The point of blocklisting is NOT just for malware, it is also to block things that cause instability in the Firefox browser.  This certainly seems to meet that second criteria.

Comment 87

[Bartłomiej Brzozowiec (BartZilla)]

(In reply to comment #76)
> Created attachment 519434 [details] [diff] [review]
> Enable blocking DLLs loaded via AppInit_Dlls
> 
> This patch fixes a compilation problem for plugin-container.exe in the previous
> patch.

This patch has review-, but in any case... there is a typo:
..
+static bool isDelayLoading =
+#ifdef _MSC_VER
+  true;
+#else
+  flase;
+#endif
..

"flase"

Comment 88

[(no longer active)]

(In reply to comment #84)
> Can't this be blocklisted somehow?

That's what we tried here.  See comment 55 as to why it doesn't work.

Comment 89

[(no longer active)]

(In reply to comment #83)
> (In reply to comment #82)
> > Another approach is for us to move this over to Evangelism to see if we can
> > contact the vendor and ask them to look into the issue?
> 
> I think this actually would be the best. But even though the author of that DLL
> is already CC'd on this bug, he never replied in the comments.

Which makes me really suspect the effectiveness of any evangelism here (as we probably can't do anything more than outreaching).

> vksaver.dll is not a malware, it's actually intended to help users, similar to
> the add-ons. It is just implemented some non-standard way to handle any
> browser, but turns out, this way is not quite compatible with Firefox. As far
> as I understand, this might be version-specific, as when such crashes occurred
> before, the update to the DLL fixed the problem.

Well, when I call it malware, I don't mean that it has bad intentions.  It's just a horrible piece of software which does everything that a malware would do:

* It's hooking into our process without us asking for it.
* It's intercepting the Windows networking library calls, and replaces them with its own.
* It's causing problems for us because it is not stable.

And it seems like all that this software is meant to do is to replace the flash audio player served by vkontakte.com by its own.  This is in fact something that a normal add-on can do by listening for http-on-examine-response and using nsITraceableChannel.  So, I really think that we should somehow get the developer of this software to use our supported extension APIs instead of hooking into our process in this way.  But it seems that this outreach has been unsuccessful so far...

Comment 90

[Scoobidiver (away)]

> It's just a horrible piece of software which does everything that a malware
> would do
Can the tech evangelism team contact anti-virus companies so that it is classified as malware?

Comment 91

[chris hofmann]

kev, [e-mail] or anyone else cc'ed here or viewing the bug. 

can you get us a contact at vkontakte.ru or help us to find a solution to reduce the crash volume with the suggestions in comment 89?

This is the #2 top crash in firfox 4.

We need to block old/existing crashy versions if possible and if its a plugin intended to server users with a better experience it needs to properly use our plugin API's.

Comment 92

[chris hofmann]

looks like we are actually offering

VKontakte.ru Downloader (music/video/photo download) 0.3.0.29 

and a development Version 0.3.0.31pre which is Not Reviewed  on AMO

see:

https://addons.mozilla.org/en-US/firefox/addon/vkontakteru-downloader-musicvi/

in the review of the experimental addon can we check to see if it exhibits the problems Ehsan  has identified in comment 89 and chekc to see if the vksaver.dll versions that are a part of that package correspond to addon version?

If these possibly newer versions have fixes already, or we can get the suggested fixes into a new addon update we just need to figure out how to excellerate updates and get people off vksaver.dll 2.2.2.0

it looks like we could be a major distribution point for this .dll

Downloads = 741,173

jorgev, can you help?

Comment 93

[[:Cww]]

If users disable this extension does this crash go away?

Comment 94

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

(In reply to comment #92)
> looks like we are actually offering
> 
> VKontakte.ru Downloader (music/video/photo download) 0.3.0.29 
> 
> and a development Version 0.3.0.31pre which is Not Reviewed  on AMO

This add-on appears to be unrelated to this bug. It doesn't have any binaries in it and I would be surprised if it caused any crashes. FWIW I looked for "vksaver" in the Add-ons MXR and couldn't find any instances of this.

Comment 95

[chris hofmann]

ok, thanks for checking.  can the VKontakte.ru Downloader developer help us track down the possible author of the crashy .dll?

Comment 96

[(no longer active)]

(In reply to comment #95)
> ok, thanks for checking.  can the VKontakte.ru Downloader developer help us
> track down the possible author of the crashy .dll?

The author of the crashy DLL is already CCed on the bug, they're just not responding!

Comment 97

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

The add-on included in the executable has the same id as Yandex.Bar on AMO: https://addons.mozilla.org/en-US/firefox/addon/yandexbar/. This listing has been abandoned for while, but I managed to get in touch with the authors. They gave me a contact email address (not in the CC list) for the vksaver tool and I just sent this contact a message.

Maybe they'll respond this way...

Comment 98

[adminnu]

Hello!

I saw this bag in a top 3 spot. Felt sorry for firefox. I'm Russian. Therefore, also tried to contact the developer, but the form submit does not work. Found the mail on whois:
whois audiovkontakte.ru
% By submitting a query to RIPN's Whois Service
% You agree to abide by the following terms of use:
% Http://www.ripn.net/about/servpol.html # 3.2 (in Russian)
% Http://www.ripn.net/about/en/servpol.html # 3.2 (in English).

domain: AUDIOVKONTAKTE.RU
nserver: ns3.nic.ru.
nserver: ns4.nic.ru.
nserver: ns8.nic.ru.
state: REGISTERED, DELEGATED, VERIFIED
person: Private Person
Phone: [phone]
fax-no: +7 000 0 million
e-mail: [e-mail]
registrar: RUCENTER-REG-RIPN
created: 2008.03.01
paid-till: 2012.03.01
source: TCI

Last updated on 2011.03.23 01:58:42 MSK / MSD
Wrote a letter to the developer. I doubt he will reply, he wrote more likely a student who has thrown the project. If you answer, accomplish your goal.
Additionally, I would like to propose a solution that can help. You wrote about VKontakte.ru Downloader. I'm worth it, is stable. Or maybe you just do not make attempts to add to blatsklist, but just to refresh audiovkontakte.ru Kontakte.ru Downloader. I think users will not even notice the change. And secondly, I think you will lose the audience, since coming to the site vkontakte.ru will constantly crash.

Comment 99

[Alexander L. Slovesnik]

I've got response from VKSaver author to my e-mail, he said that he is going to fix this bug ASAP.
I've forwarded his response to Chris Hofmann and Ehsan Akhgari.

Comment 100

[(no longer active)]

This is the latest response from the VKSaver author that Alexander has kindly forwarded to me:

Hi, Ehsan and Chris. VKSaver author have sent me news update on VKSaver
development.
The bad news - he is unable to reproduce Firefox crash with VKSaver
installed.
The good news - he has rewrote VKSaver, so VKSaver will act as proxy, and
VKSaver crashes will not affect Firefox. New version of VKSaver currently
undergoing testing and hopefully will be available for public in few days.
Regarding Ehsan's proposal to use Firefox API, described in
https://bugzilla.mozilla.org/show_bug.cgi?id=614966#c89 , - he is answered
that it will make program more complicated.

I don't think that the presented plan can do anything useful in terms of making the existing users not crash with vksaver installed.

Comment 101

[Alexander L. Slovesnik]

I've got another e-mail from VKSaver author. He just has released VKSaver 3.0 on http://audiovkontakte.ru/
VKSaver has built-in update system, so hopefully all users of VKSaver 2.x will be updated on 3.0 in a short time.

Comment 102

[Daniel Veditz [:dveditz]]

Comment on attachment 512863 [details] [diff] [review]
Blocklist vksaver.dll up to 2.2.2.0

Didn't make the code-freeze for non-blockers, you can try again next time.

Comment 103

[(no longer active)]

Comment on attachment 512863 [details] [diff] [review]
Blocklist vksaver.dll up to 2.2.2.0

This patch is not really useful anyways.

Comment 104

[Robert Kaiser]

There seems to be a vksaver3.dll out there now that has a fast-rising crash, the first instances being reported on 2011-04-10: https://crash-stats.mozilla.com/report/list?signature=vksaver3.dll%400x33ec

Is this the same thing?

Comment 105

[(no longer active)]

(In reply to comment #104)
> There seems to be a vksaver3.dll out there now that has a fast-rising crash,
> the first instances being reported on 2011-04-10:
> https://crash-stats.mozilla.com/report/list?signature=vksaver3.dll%400x33ec
> 
> Is this the same thing?

Probably.  :(  I still think that the best option for us is to blocklist this DLL, since the new version doesn't seem stable either.

Comment 106

[(no longer active)]

I believe that attachment 519434 [details] [diff] [review] was the best thing that I can think of for this bug.  Besides that, I'm not sure what should be done here.

Comment 107

[Scoobidiver (away)]

It happens with vksaver.dll 2.2.2.0 or vksaver3.dll 3.1.0.3.

Comment 108

[Emanuel Hoogeveen [:ehoogeveen]]

How would the delayed loading for xul.dll and the like interact with things like bug 632404?

Comment 109

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

I believe we're already delayloading a bunch of things.  See http://mxr.mozilla.org/mozilla-central/source/browser/app/Makefile.in#189

Comment 110

[Scoobidiver (away)]

With VKsaver 3.1 combined signatures (including vksaver.dll@0x3d66), it is #25 top browser crasher in 5.0.

Comment 111

[Scoobidiver (away)]

Here are correlations with the latest VKSaver version for the top crashers:
* vksaver3.dll@0x2e55|EXCEPTION_ACCESS_VIOLATION_EXEC (74 crashes)
    100% (74/74) vs.   1% (1279/101282) vksaver3.dll 3.1.0.3
* vksaver.dll@0x3d66|EXCEPTION_ACCESS_VIOLATION_EXEC (64 crashes)
    100% (64/64) vs.   1% (1279/101282) vksaver3.dll 3.1.0.3
* arena_malloc_small|EXCEPTION_ACCESS_VIOLATION_READ (75 crashes)
     76% (57/75) vs.   1% (1279/101282) vksaver3.dll 3.1.0.3
With these 3 crash signatures, it's #18 top crasher in 8.0.

Comment 112

[Alex Keybl [:akeybl]]

Should we re-consider the r- of attachment 519434 [details] [diff] [review] since this is causing a top crasher? If so, let's re-open 708000 at the same time.

Comment 113

[Henri Sivonen (:hsivonen)]

(In reply to Ehsan Akhgari [:ehsan] from comment #81)
> (In reply to comment #79)
> > (In reply to comment #78)
> > > So, should we WONTFIX this bug?
> > WONTFIXing this bug will leave users in cold. At least they should be warned
> > about well-known AppInit badware/malware loaded along with Firefox.
> 
> I don't think we'd want to have such warnings.  Firefox is not a malware
> detection tool!

Sure, alerting the user to uninstall something isn't a smooth user experience, but crashing isn't, either. Since blocking the DLL isn't feasible, I think it would make sense to let the user know about badware instead of just being cool about it and keeping crashing.

FWIW, dialogs advising the users about other software aren't without precedent. E.g. Photoshop tells the user to update GPU drivers on Windows under some conditions.

Comment 114

[Scoobidiver (away)]

I added crash signatures for VKsaver 3.1.0.3.

Comment 115

[Scoobidiver (away)]

It's #113 top browser crasher in 15.0.1.

Comment 116

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

Closing old blocklist bugs. Please reopen if the problem still exists.