Proxifier Portable Network Engine crashing Firefox during DNS lookups
Categories
(External Software Affecting Firefox :: Other, defect, P5)
Tracking
(Not tracked)
People
(Reporter: gsvelto, Unassigned)
Details
(Keywords: crash)
Crash Data
Crash report: https://crash-stats.mozilla.org/report/index/937ed370-4658-49eb-b205-e0c250210312
Reason: EXCEPTION_ACCESS_VIOLATION_EXEC
Top 10 frames of crashing thread:
0 prxdrvpe64.dll prxdrvpe64.dll@0x5387
1 ws2_32.dll QueryDnsForFamily
2 ws2_32.dll QueryDns
3 ws2_32.dll LookupAddressForName
4 ws2_32.dll GetAddrInfoW
5 ws2_32.dll getaddrinfo
6 nss3.dll PR_GetAddrInfoByName nsprpub/pr/src/misc/prnetdb.c:2164
7 xul.dll mozilla::net::GetAddrInfo netwerk/dns/GetAddrInfo.cpp:362
8 xul.dll nsHostResolver::ThreadFunc netwerk/dns/nsHostResolver.cpp:2197
9 xul.dll mozilla::detail::RunnableMethodImpl< xpcom/threads/nsThreadUtils.h:1201
The module causing the crash appears to have been unloaded before we could write the minidumps so it's hard to tell which version is causing the crashes.
Comment 1•4 years ago
|
||
Adding signatures of 32bit crashes.
Comment 2•4 years ago
|
||
Two versions v3 and v4 of Proxifier Portable Edition are available at https://www.proxifier.com/download/, which contains PrxDrvPE[64].dll v3.42.0.1 and v4.1.0.4 respectively.
The module was already unloaded at crash, but analyzing their hook behavior, luckily we can guess the module's version from the crash address, which is
- If the lowest WORD of the crash address is 0x5387, the module should be v3.42.0.1.
- If the lowest WORD of the crash address is 0x5557, the module should be v4.1.0.4.
This idea is based on how their module works. It detours WS2_32!WSALookupServiceNextW
, and the crashing address is an address in their detour function returned from WS2_32!WSALookupServiceNextW
. Therefore, if someone unloads their module while WS2_32!WSALookupServiceNextW
runs, this crash happens. I could not reproduce the crash. It may be caused by another third-party application.
WS2_32!WSALookupServiceNextW:
00007ffa`de12bae0 6850536fcb push 0FFFFFFFFCB6F5350h
00007ffa`de12bae5 c7442404fa7f0000 mov dword ptr [rsp+4],7FFAh
00007ffa`de12baed c3 ret
PrxDrvPE64!InitFilter3+0x42d0:
00007ffa`cb6f5350 e90b000000 jmp PrxDrvPE64!InitFilter3+0x42e0 (00007ffa`cb6f5360)
PrxDrvPE64!InitFilter3+0x42e0:
00007ffa`cb6f5360 4889742410 mov qword ptr [rsp+10h],rsi
00007ffa`cb6f5365 57 push rdi
00007ffa`cb6f5366 4883ec20 sub rsp,20h
00007ffa`cb6f536a 803d4fda010000 cmp byte ptr [PrxDrvPE64!InitFilter3+0x21d40 (00007ffa`cb712dc0)],0
00007ffa`cb6f5371 498bf9 mov rdi,r9
00007ffa`cb6f5374 488bf1 mov rsi,rcx
00007ffa`cb6f5377 7452 je PrxDrvPE64!InitFilter3+0x434b (00007ffa`cb6f53cb)
00007ffa`cb6f5379 488b05e0da0100 mov rax,qword ptr [PrxDrvPE64!InitFilter3+0x21de0 (00007ffa`cb712e60)]
00007ffa`cb6f5380 4885c0 test rax,rax
00007ffa`cb6f5383 7452 je PrxDrvPE64!InitFilter3+0x4357 (00007ffa`cb6f53d7)
00007ffa`cb6f5385 ffd0 call rax ----> (dynamic code) --> WS2_32!WSALookupServiceNextW+0xf
WS2_32!WSALookupServiceNextW+0xf:
00007ffa`de12baef 4156 push r14
00007ffa`de12baf1 4883ec40 sub rsp,40h
...
00007ffa`de12bbde c3 ret
PrxDrvPE64!InitFilter3+0x4307:
00007ffa`cb6f5387 85c0 test eax,eax <<<< crash if the module was unloaded
Most of the crashes are 0x5387 i.e. v3.42.0.1, but one crash indicates the crash with v4.1.0.4. Maybe it's because the latest version was released this month.
Comment 3•4 years ago
|
||
I found another interesting fact. There are a few crash reports with different signatures where PrxDrvPE[64].dll was still loaded.
- 07549f69-07d9-4895-8b37-9d2010210228
- 8646c1d2-275e-41af-87f4-1c51b0210311
- f5da2992-2568-4695-8fc3-426040210317
Looking at these dumps, the path to PrxDrvPE[64].dll implies the module was bundled with a VPN application. In the above examples, it's ILC VPN, 20SPEED, and TikNet VPN respectively, and googling them shows a Persian website.
It's possible that this crash happens only when it's bundled with a bad VPN application. If that's true, blocking PrxDrvPE[64].dll will break customers using other good VPN applications.
Comment 4•4 years ago
|
||
I opened a support ticket https://support.proxifier.com/Tickets/Ticket/View/OXJ-652-51050 for this issue.
Comment 5•4 years ago
|
||
Hello, I am from Proxifier team.
Thanks for reporting this. We will try to investigate this problem.
Is there a way to get some actual minidumps? It does not seem that I can do this form my Mozzila account.
It's possible that this crash happens only when it's bundled with a bad VPN application. If that's true, blocking PrxDrvPE[64].dll will break customers using other good VPN applications.
This assumption may be correct. We do not authorize any use of Proxifier as a bundle in any third-party products. In many cases, such products use pirate version of our software. It is also not clear how the integration is done.
Reporter | ||
Comment 6•4 years ago
|
||
(In reply to Sergey Konovalov from comment #5)
Is there a way to get some actual minidumps? It does not seem that I can do this form my Mozzila account.
Special access rights are required to access the minidumps due to privacy concerns, only a handful of people within Mozilla have them. I happen to be one of them so if you need some specific information I can look it up for you.
Comment 7•4 years ago
|
||
(In reply to Sergey Konovalov from comment #5)
Is there a way to get some actual minidumps? It does not seem that I can do this form my Mozzila account.
As Gabriele mentioned, our policy does not allow us to share minidumps with non-employees.
If what happened was that PrxDrvPE64.dll was unloaded while running a hook function, can your code prevent such unexpected unloading?
If we can do something, it would be to add a diagnostics assert to find out who unloads PrxDrvPE64.dll.
Comment 8•4 years ago
|
||
Thanks for the information.
We have investigated the issue. Your assumptions are correct. The crash most likely happens when a blocking Winsock function returns to Proxifier hook function but PrxDrvPE.dll that hosts this function is unloaded.
Windows automatically unloads PrxDrvPE.dll when Proxifier.exe (the process that calls SetWindowsHookEx) exits.
The crash is unlikely to happen when Proxifier is used in a regular scenario as a standalone application. But when it is illegally integrated into a third-party product, I believe that this host product may just kill Proxifier.exe process. This significantly increases the chances of PrxDrvPE.dll crash.
We are going to add some logic that properly handles DLL unload in all scenarios. Although, it will take some time to add the changes and to test everything.
Comment 9•4 years ago
|
||
(In reply to Sergey Konovalov from comment #8)
Windows automatically unloads PrxDrvPE.dll when Proxifier.exe (the process that calls SetWindowsHookEx) exits.
Ah, that sounds like it! Thank you for taking care of this issue.
Comment 10•4 years ago
|
||
We have already found a possible solution. I will post here once the update is available.
Please note however, that we will update version 4 only. Version 3 will stay as it is because the problem is not critical and it seems to manly affect illegal uses.
Comment 11•4 years ago
|
||
(In reply to Sergey Konovalov from comment #10)
We have already found a possible solution. I will post here once the update is available.
Please note however, that we will update version 4 only. Version 3 will stay as it is because the problem is not critical and it seems to manly affect illegal uses.
I see. Even though Version 3 is updated, we're not sure those VPN applications update a bundled Proxifier, so that decision makes sense to me.
Updated•3 years ago
|
Comment 12•2 years ago
|
||
Closing because no crashes reported for 12 weeks.
Description
•