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

RESOLVED WONTFIX

Status

()

--
critical
RESOLVED WONTFIX
8 years ago
3 years ago

People

(Reporter: scoobidiver, Unassigned)

Tracking

(Blocks: 1 bug, {crash})

unspecified
x86
Windows XP
crash
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 .x+, blocking1.9.2 -, status1.9.2 wanted)

Details

(Whiteboard: [3rd-party-bustage], crash signature)

Attachments

(3 attachments, 2 obsolete attachments)

(Reporter)

Description

8 years ago
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

8 years ago
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)?
blocking2.0: --- → ?
Keywords: topcrash
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.
(Reporter)

Comment 3

8 years ago
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.
(Reporter)

Comment 4

8 years ago
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.
blocking2.0: ? → ---
Presumably it could be installed as an LSP, but I don't see it in our reported LSP info (looking at the raw JSON).
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.
The bug where we blocklisted this last time was Bug 540692.

Comment 8

8 years ago
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.
(Reporter)

Comment 9

8 years ago
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.
CC'ing vksaver developer.

Comment 11

8 years ago
(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.
blocking2.0: --- → ?

Comment 12

8 years ago
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.
blocking2.0: ? → -
Component: Networking → Blocklisting
Product: Core → addons.mozilla.org
QA Contact: networking → blocklisting
Version: Trunk → unspecified
(Reporter)

Comment 13

8 years ago
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.
blocking2.0: - → ?
Summary: crash [@ send ] [@ send | vksaver.dll@0x5d4a ] with vksaver.dll 2.2.2.0 → crash [@ send ] [@ send | vksaver.dll@0x5d4a ] [@ vksaver.dll@0x3398 ] [@ vksaver.dll@0x3392 ] [@ vksaver.dll@0x4917 ] [@ vksaver.dll@0x3064 ] with vksaver.dll 2.2.2.0 and below

Comment 14

8 years ago
#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.
blocking1.9.2: --- → ?
blocking2.0: ? → .x
status1.9.1: --- → .2-fixed

Updated

8 years ago
status1.9.1: .2-fixed → ---
(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
(Reporter)

Comment 16

8 years ago
> 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.
(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.
(Reporter)

Comment 18

8 years ago
> 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

8 years ago
(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

8 years ago
Created attachment 512863 [details] [diff] [review]
Blocklist vksaver.dll up to 2.2.2.0
Assignee: nobody → ehsan
Status: NEW → ASSIGNED
Attachment #512863 - Flags: review?(benjamin)
(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

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

Yes, we should do this.
Attachment #512863 - Flags: review?(benjamin)
Attachment #512863 - Flags: review+
Attachment #512863 - Flags: approval1.9.2.15?

Comment 23

8 years ago
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 on attachment 512863 [details] [diff] [review]
Blocklist vksaver.dll up to 2.2.2.0

a2.0=dbaron

Updated

8 years ago
Keywords: checkin-needed
Whiteboard: [needs landing]

Comment 25

8 years ago
http://hg.mozilla.org/mozilla-central/rev/1249116e394c
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [needs landing]
Not blocking, but good to take.
blocking1.9.2: ? → -
status1.9.2: --- → wanted
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
Attachment #512863 - Flags: approval1.9.2.15? → approval1.9.2.15+
(Reporter)

Comment 28

8 years ago
Crashes still happen with vksaver dlls without version. See:
bp-a8bbe3aa-3e16-4cf2-bb4b-fccf32110219
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 29

8 years ago
(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?
(Reporter)

Comment 30

8 years ago
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

8 years ago
(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?
(Reporter)

Comment 32

8 years ago
> 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.
(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.
(Reporter)

Comment 34

8 years ago
The add-ons blocklisting is referenced in http://www.mozilla.com/en-US/blocklist/.
Where is the DLL blocklisting referenced?
(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
(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.
(Reporter)

Comment 37

8 years ago
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?
You mean a public facing web page similar to the blocklisting website... perhaps.

cc'ing LegNeato and johnath is already cc'd
(Reporter)

Comment 39

8 years ago
> 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.
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.
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

8 years ago
(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...
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

8 years ago
(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

8 years ago
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...
(Reporter)

Comment 46

8 years ago
> 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

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

Comment 49

8 years ago
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?
(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

8 years ago
(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

8 years ago
Created attachment 516883 [details]
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

8 years ago
> other possible malware signatures

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

Comment 54

8 years ago
This is interesting.  Whatever is going on here might also have some correlation to bug 633445.
Depends on: 633445

Comment 55

8 years ago
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 yasearch@yandex.ru 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 yasearch@yandex.ru 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!

Updated

8 years ago
See Also: → bug 639657
(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 yasearch@yandex.ru 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 audiovkontakte.ru@gmail.com is the VKSaver author's email. Can the author provide his comments on this issue please?

Comment 57

8 years ago
(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 yasearch@yandex.ru

the rest of the signatures had a mixed bag.

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

Comment 58

8 years ago
Created attachment 517632 [details]
signature,crash-report-link,fxversion,add-compat-check-status,vksaver-version-info,yandex-search-installed-status
(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

8 years ago
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

8 years ago
> 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
(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

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

 110 vksaver.dll@0x3398 <td>yasearch@yandex.ru</td>
  93 vksaver.dll@0x3398 no yasearch

 110 vksaver.dll@0x3392 <td>yasearch@yandex.ru</td>
  87 vksaver.dll@0x3392 no yasearch

  37 vksaver.dll@0x4917 <td>yasearch@yandex.ru</td>
  22 vksaver.dll@0x4917 no yasearch

  33 vksaver.dll@0x3064 no yasearch

   1 vksaver.dll@0x4868 <td>yasearch@yandex.ru</td>

   1 vksaver.dll@0x4d99 <td>yasearch@yandex.ru</td>

   1 vksaver.dll@0x3e06 <td>yasearch@yandex.ru</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

8 years ago
(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

8 years ago
(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

8 years ago
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

8 years ago
(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...
To a rough first approximation, anything in tier_app for Firefox.
Actually, that's wrong (I forgot about browsercomps.dll).

nsBrowserApp.cpp and possibly some static libs from elsewhere.

Comment 70

8 years ago
(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

8 years ago
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

8 years ago
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

8 years ago
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

8 years ago
Created attachment 519272 [details] [diff] [review]
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.
Attachment #519272 - Flags: review?(benjamin)

Comment 75

8 years ago
(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

8 years ago
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.
Attachment #519272 - Attachment is obsolete: true
Attachment #519434 - Flags: review?(benjamin)
Attachment #519272 - Flags: review?(benjamin)

Comment 77

8 years ago
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.
Attachment #519434 - Flags: review?(benjamin) → review-

Comment 78

8 years ago
(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?
(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.
(Reporter)

Comment 80

8 years ago
> 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

8 years ago
(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

8 years ago
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.
(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.
Can't this be blocklisted somehow?
(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?
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.
(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

8 years ago
(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

8 years ago
(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...
(Reporter)

Comment 90

8 years ago
> 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

8 years ago
kev, audiovkontakte.ru@gmail.com 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

8 years ago
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

8 years ago
If users disable this extension does this crash go away?
(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

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

Comment 96

8 years ago
(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!
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

8 years ago
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: +7 000 0000000
fax-no: +7 000 0 million
e-mail: mofsound@rambler.ru
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.
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

8 years ago
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.
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 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.
Attachment #512863 - Flags: approval1.9.2.17+ → approval1.9.2.17-

Comment 103

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

This patch is not really useful anyways.
Attachment #512863 - Attachment is obsolete: true

Comment 104

8 years ago
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

8 years ago
(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.

Updated

8 years ago
Summary: crash [@ send ] [@ send | vksaver.dll@0x5d4a ] [@ vksaver.dll@0x3398 ] [@ vksaver.dll@0x3392 ] [@ vksaver.dll@0x4917 ] [@ vksaver.dll@0x3064 ] with vksaver.dll 2.2.2.0 and below → crash [@ send ] [@ send | vksaver.dll@0x5d4a ] [@ vksaver.dll@0x3398 ] [@ vksaver.dll@0x3392 ] [@ vksaver.dll@0x4917 ] [@ vksaver.dll@0x3064 ][@ vksaver3.dll@0x33ec ] with VKSaver

Comment 106

8 years ago
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.
Assignee: ehsan → nobody
(Reporter)

Updated

8 years ago
Summary: crash [@ send ] [@ send | vksaver.dll@0x5d4a ] [@ vksaver.dll@0x3398 ] [@ vksaver.dll@0x3392 ] [@ vksaver.dll@0x4917 ] [@ vksaver.dll@0x3064 ][@ vksaver3.dll@0x33ec ] with VKSaver → crash [@ send ] [@ send | vksaver.dll@0x5d4a ] [@ vksaver.dll@0x3398 ] [@ vksaver.dll@0x3392 ] [@ vksaver.dll@0x4917 ] [@ vksaver.dll@0x3064 ][@ vksaver3.dll@0x3454 ][@ vksaver3.dll@0x33ec ] with VKSaver
(Reporter)

Comment 107

8 years ago
It happens with vksaver.dll 2.2.2.0 or vksaver3.dll 3.1.0.3.
Summary: crash [@ send ] [@ send | vksaver.dll@0x5d4a ] [@ vksaver.dll@0x3398 ] [@ vksaver.dll@0x3392 ] [@ vksaver.dll@0x4917 ] [@ vksaver.dll@0x3064 ][@ vksaver3.dll@0x3454 ][@ vksaver3.dll@0x33ec ] with VKSaver → crash [@ send ][@ send | vksaver.dll@0x5d4a ][@ vksaver.dll@0x3398 ][@ vksaver.dll@0x3392 ][@ vksaver.dll@0x3d66 ][@ vksaver.dll@0x4917 ][@ vksaver.dll@0x39d6 ][@ vksaver3.dll@0x3064 ][@ vksaver3.dll@0x2e55 ] with VKSaver
(Reporter)

Updated

8 years ago
Blocks: 467167
How would the delayed loading for xul.dll and the like interact with things like bug 632404?
(Assignee)

Updated

8 years ago
Crash Signature: [@ send ] [@ send | vksaver.dll@0x5d4a ] [@ vksaver.dll@0x3398 ] [@ vksaver.dll@0x3392 ] [@ vksaver.dll@0x3d66 ] [@ vksaver.dll@0x4917 ] [@ vksaver.dll@0x39d6 ] [@ vksaver3.dll@0x3064 ] [@ vksaver3.dll@0x2e55 ]
(Reporter)

Comment 110

7 years ago
With VKsaver 3.1 combined signatures (including vksaver.dll@0x3d66), it is #25 top browser crasher in 5.0.
Crash Signature: [@ send ] [@ send | vksaver.dll@0x5d4a ] [@ vksaver.dll@0x3398 ] [@ vksaver.dll@0x3392 ] [@ vksaver.dll@0x3d66 ] [@ vksaver.dll@0x4917 ] [@ vksaver.dll@0x39d6 ] [@ vksaver3.dll@0x3064 ] [@ vksaver3.dll@0x2e55 ] → [@ send ] [@ send | vksaver.dll@0x5d4a ] [@ vksaver.dll@0x3398 ] [@ vksaver.dll@0x3392 ] [@ vksaver.dll@0x3d66 ] [@ vksaver.dll@0x4917 ] [@ vksaver.dll@0x39d6 ] [@ vksaver3.dll@0x3064 ] [@ vksaver3.dll@0x2e55 ]
Summary: crash [@ send ][@ send | vksaver.dll@0x5d4a ][@ vksaver.dll@0x3398 ][@ vksaver.dll@0x3392 ][@ vksaver.dll@0x3d66 ][@ vksaver.dll@0x4917 ][@ vksaver.dll@0x39d6 ][@ vksaver3.dll@0x3064 ][@ vksaver3.dll@0x2e55 ] with VKSaver → Various crashes with VKSaver 2.2 (vksaver.dll@...) or VKSaver 3.1 (vksaver.dll@0x3d66, vksaver3.dll@0x2e55)
(Reporter)

Comment 111

7 years ago
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.
Crash Signature: [@ send ] [@ send | vksaver.dll@0x5d4a ] [@ vksaver.dll@0x3398 ] [@ vksaver.dll@0x3392 ] [@ vksaver.dll@0x3d66 ] [@ vksaver.dll@0x4917 ] [@ vksaver.dll@0x39d6 ] [@ vksaver3.dll@0x3064 ] [@ vksaver3.dll@0x2e55 ] → vksaver.dll@0x3643 ] [@ arena_malloc_small ] [@ send ] [@ send | vksaver.dll@0x5d4a ] [@ vksaver.dll@0x3398 ] [@ vksaver.dll@0x3392 ] [@ vksaver.dll@0x3d66 ] [@ vksaver.dll@0x4917 ] [@ vksaver.dll@0x39d6 ] [@ vksaver3.dll@0x3064 ] [@ vksaver3.dll…

Updated

7 years ago
Depends on: 708000
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.
(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.
(Reporter)

Updated

7 years ago
Depends on: 636113
(Reporter)

Updated

7 years ago
Depends on: 716345
(Reporter)

Comment 114

7 years ago
I added crash signatures for VKsaver 3.1.0.3.
Crash Signature: vksaver.dll@0x3643 ] [@ arena_malloc_small ] [@ send ] [@ send | vksaver.dll@0x5d4a ] [@ vksaver.dll@0x3398 ] [@ vksaver.dll@0x3392 ] [@ vksaver.dll@0x3d66 ] [@ vksaver.dll@0x4917 ] [@ vksaver.dll@0x39d6 ] [@ vksaver3.dll@0x3064 ] [@ vksaver3.dll… → vksaver.dll@0x3643] [@ vksaver.dll@0x3653] [@ vksaver.dll@0x3533] [@ vksaver.dll@0x3746] [@ send] [@ send | vksaver.dll@0x5d4a] [@ vksaver.dll@0x3398] [@ vksaver.dll@0x3392] [@ vksaver.dll@0x3d66] [@ vksaver.dll@0x4917] [@ vksaver.dll@0x39d6] [@…
Whiteboard: [3rd-party-bustage]
(Reporter)

Updated

7 years ago
Crash Signature: vksaver.dll@0x3643] [@ vksaver.dll@0x3653] [@ vksaver.dll@0x3533] [@ vksaver.dll@0x3746] [@ send] [@ send | vksaver.dll@0x5d4a] [@ vksaver.dll@0x3398] [@ vksaver.dll@0x3392] [@ vksaver.dll@0x3d66] [@ vksaver.dll@0x4917] [@ vksaver.dll@0x39d6] [@… → vksaver3.dll@0x2e55] [@ vksaver.dll@0x3960] [@ vksaver.dll@0x3643] [@ vksaver.dll@0x3653] [@ vksaver.dll@0x3533] [@ vksaver.dll@0x3746] [@ send] [@ send | vksaver.dll@0x3533] [@ send | vksaver.dll@0x595a] [@ send | vksaver.dll@0x5d4a] [@ vksaver.…
(Reporter)

Comment 115

6 years ago
It's #113 top browser crasher in 15.0.1.
Keywords: topcrash
(Reporter)

Updated

6 years ago
Crash Signature: [@ send] [@ send | vksaver.dll@0x3533] [@ send | vksaver.dll@0x595a] [@ send | vksaver.dll@0x5d4a] [@ vksaver.dll@0x3398] [@ vksaver.dll@0x3392] [@ vksaver.dll@0x3d66] [@ vksaver.dll@0x4917] [@ vksaver.dll@0x39d6] [@ vksaver3.dll@0x3064] [@ vksa… → [@ send] [@ send | vksaver.dll@0x3533] [@ send | vksaver.dll@0x595a] [@ send | vksaver.dll@0x5d4a] [@ vksaver.dll@0x3398] [@ vksaver.dll@0x3392] [@ vksaver.dll@0x3d66] [@ vksaver.dll@0x4917] [@ vksaver.dll@0x39d6] [@ vksaver.dll@0x3960] [@ vksav…
Closing old blocklist bugs. Please reopen if the problem still exists.
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago5 years ago
Resolution: --- → WONTFIX
(Assignee)

Updated

3 years ago
Product: addons.mozilla.org → Toolkit
You need to log in before you can comment on or make changes to this bug.