Closed Bug 1698057 Opened 4 years ago Closed 2 years ago

Proxifier Portable Network Engine crashing Firefox during DNS lookups

Categories

(External Software Affecting Firefox :: Other, defect, P5)

Unspecified
Windows 10

Tracking

(Not tracked)

RESOLVED WORKSFORME

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.

Adding signatures of 32bit crashes.

Crash Signature: [@ prxdrvpe64.dll | QueryDnsForFamily] [@ prxdrvpe64.dll | WSALookupServiceEnd] → [@ prxdrvpe64.dll | QueryDnsForFamily] [@ prxdrvpe64.dll | WSALookupServiceEnd] [@ prxdrvpe.dll | QueryDnsForFamily] [@ prxdrvpe.dll | _PR_MD_CONNECT | SocketConnect | pl_DefConnect]

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.

I found another interesting fact. There are a few crash reports with different signatures where PrxDrvPE[64].dll was still loaded.

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.

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.

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

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

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.

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

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.

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

Severity: -- → S3
Priority: -- → P5

Closing because no crashes reported for 12 weeks.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.