Closed Bug 1601986 Opened 5 years ago Closed 4 years ago

Crash in [@ mozglue.dll | arena_t::DallocSmall | je_free | mozilla::DllServices::~DllServices] (possibly antivirus hooking)


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

Windows 10


(firefox-esr68 unaffected, firefox71 wontfix, firefox72 wontfix, firefox73 wontfix, firefox74 wontfix)

Tracking Status
firefox-esr68 --- unaffected
firefox71 --- wontfix
firefox72 --- wontfix
firefox73 --- wontfix
firefox74 --- wontfix


(Reporter: philipp, Unassigned)




(Keywords: crash, csectype-dos, regression)

Crash Data

This bug is for crash report bp-56d47c3b-22a4-4b28-9e90-3857d0191206.

Top 10 frames of crashing thread:

0  @0x7ffd478500e4 
1 mozglue.dll mozglue.dll@0x483f 
2 mozglue.dll mozglue.dll@0x483f 
3 mozglue.dll arena_t::DallocSmall memory/build/mozjemalloc.cpp:3243
4 mozglue.dll je_free memory/build/malloc_decls.h:54
5 xul.dll void mozilla::DllServices::~DllServices toolkit/xre/WinDllServices.h:27
6 xul.dll void mozilla::ClearOnShutdown_Internal::PointerClearer<mozilla::StaticAutoPtr<mozilla::TIPMessageHandler> >::Shutdown xpcom/base/ClearOnShutdown.h:85
7 xul.dll mozilla::KillClearOnShutdown xpcom/base/ClearOnShutdown.cpp:53
8 xul.dll mozilla::ShutdownXPCOM xpcom/build/XPCOMInit.cpp:667
9 xul.dll void ScopedXPCOMStartup::~ScopedXPCOMStartup toolkit/xre/nsAppRunner.cpp:1246

this crash signature is starting to sho up in low volume on firefox after 71.0 got publicly released - perhaps related to the changes from bug 1542830?

Is this the right component for this? It's not "External" software, this is Firefox itself crashing.

Flags: needinfo?(jmathies)
Keywords: sec-high

Toshi, could you take a look here please.

Flags: needinfo?(jmathies) → needinfo?(tkikuchi)

The crash happened at a trampoline of user32!UnhookWindowsHookEx which was incorrectly crafted by someone. In the crash dump, user32!UnhookWindowsHookEx was not actually hooked. Probably it was already unhooked during shutdown process.

0:003> u 00007ffd`478500e0 <--- looks like a trampoline of user32!UnhookWindowsHookEx
00007ffd`478500e0 4883ec28        sub     rsp,28h
00007ffd`478500e4 833db1d4070005  cmp     dword ptr [00007ffd`478cd59c],5   <<<< crash because the address is invalid
00007ffd`478500eb ff2500000000    jmp     qword ptr [00007ffd`478500f1] ---> user32!UnhookWindowsHookEx+0xb

0:003> dps 00007ffd`478500f1 l1
00007ffd`478500f1  00007ffd`c76ca4cb user32!UnhookWindowsHookEx+0xb

00007ffd`c76ca4c0 4883ec28        sub     rsp,28h
00007ffd`c76ca4c4 833db1d4070005  cmp     dword ptr [user32!g_systemCallFilterId (00007ffd`c774797c)],5
00007ffd`c76ca4cb 740b            je      user32!UnhookWindowsHookEx+0x18 (00007ffd`c76ca4d8)
00007ffd`c76ca4cd 4883c428        add     rsp,28h
00007ffd`c76ca4d1 48ff25d0ea0500  jmp     qword ptr [user32!_imp_NtUserUnhookWindowsHookEx (00007ffd`c7728fa8)]
00007ffd`c76ca4d8 e82777fdff      call    user32!CLocalHookManager::RemoveHook (00007ffd`c76a1c04)
00007ffd`c76ca4dd 0fb6c0          movzx   eax,al
00007ffd`c76ca4e0 4883c428        add     rsp,28h

The problem is the original code 833db1d4070005 was simply copied without considering the operand was a relative address. That's why the crash happened.

As far as I searched the code, none of our code hooks user32!UnhookWindowsHookEx. Even though somebody tried, our detour would fail because we cannot handle the 2nd instruction cmp.

Looking at "Telemetry environment" field of crash reports, I can see "Avast Antivirus" is installed in many instances. Maybe they hook user32!UnhookWindowsHookEx. At this point, I don't think this is a regression from our change.

I'm still not sure why the crashing thread, which was calling mozglue!arena_t::DallocSmall, was running UnhookWindowsHookEx. I'll try to install Avast to see their behavior.

Flags: needinfo?(tkikuchi)

I may need a second pair of eyes, but I think:

  1. This crash is not new in 71.
  2. This crash is not a security issue.

First of all, the signature does not indicate the crashing functions correctly. It's showing the symbols of garbage data in the stack.

The correct crashing frame should be like below, because this is the only chance we call UnhookWindowsHookEx at shutdown. Before we call UnhookWindowsHookEx, the thread ran DllServices::~DllServices, DallocSmall, and so on. That's why those addresses are in the stack, but it has nothing to do with the crash.

00 0000004c`007ff638 (trampoline addr) (hooked UnhookWindowsHookEx)
01 (Inline Function) --------`-------- xul!mozilla::TIPMessageHandler::~TIPMessageHandler+0xe
02 (Inline Function) --------`-------- xul!mozilla::StaticAutoPtr<mozilla::TIPMessageHandler>::Assign+0x1d
03 (Inline Function) --------`-------- xul!mozilla::StaticAutoPtr<mozilla::TIPMessageHandler>::operator=+0x1d
04 0000004c`007ff640 00007ffd`1edf75f9 xul!mozilla::ClearOnShutdown_Internal::PointerClearer<mozilla::StaticAutoPtr<mozilla::TIPMessageHandler> >::Shutdown+0x2b
05 0000004c`007ff670 00007ffd`1ee81385 xul!mozilla::KillClearOnShutdown+0x69
06 0000004c`007ff6c0 00007ffd`2217523a xul!mozilla::ShutdownXPCOM+0x215
07 0000004c`007ff720 00007ffd`1e4f2e05 xul!ScopedXPCOMStartup::~ScopedXPCOMStartup+0xba
08 (Inline Function) --------`-------- xul!mozilla::DefaultDelete<ScopedXPCOMStartup>::operator()+0x8
09 (Inline Function) --------`-------- xul!mozilla::UniquePtr<ScopedXPCOMStartup,mozilla::DefaultDelete<ScopedXPCOMStartup> >::reset+0x1b
0a (Inline Function) --------`-------- xul!mozilla::UniquePtr<ScopedXPCOMStartup,mozilla::DefaultDelete<ScopedXPCOMStartup> >::operator=+0x1b
0b 0000004c`007ff780 00007ffd`1e4f293c xul!XREMain::XRE_main+0x435

This means the same crash could be appeared as a different signature, and actually I found the following signature is also claiming the same crash.

(To verify that, open a raw dump with windows debugger and run .excr. If the crashing address is not mapped into any module and its instruction is cmp dword ptr [some address],5, that should be this issue.)

Regarding vulnerability, I think this is not a security issue. The root cause is somebody just copied a rel32 operand. This is not UAF. The code tried to access a relative address based on the location of a trampoline, and its offset is just a copy from user32!UnhookWindowsHookEx. It cannot be controlled by an attacker.

The priority flag is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jmathies)
Flags: needinfo?(jmathies) → needinfo?(dveditz)
Priority: -- → P3
Group: core-security
Component: Telemetry → Other
Flags: needinfo?(dveditz)
Summary: Crash in [@ mozglue.dll | arena_t::DallocSmall | je_free | mozilla::DllServices::~DllServices] → Crash in [@ mozglue.dll | arena_t::DallocSmall | je_free | mozilla::DllServices::~DllServices] (possibly antivirus hooking)

Closing because no crashes reported for 12 weeks.

Closed: 4 years ago
Resolution: --- → WORKSFORME
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.