Closed Bug 1615401 Opened 4 years ago Closed 4 years ago

Content process of 32bit firefox.exe crashes on 32bit OS if Windows compatibility mode is set to Win7

Categories

(Core :: Security: Process Sandboxing, defect, P3)

x86
Windows
defect

Tracking

()

VERIFIED FIXED
mozilla75
Tracking Status
firefox75 --- verified

People

(Reporter: toshi, Assigned: toshi)

References

Details

Attachments

(3 files)

Seems we incorrectly detour 32bit NtOpenFile.

Here's the crashing point:

1:003> r
eax=00000000 ebx=00000000 ecx=01041f20 edx=775c3d10 esi=00000000 edi=00000000
eip=0004b60e esp=0077f1c8 ebp=0077f1e8 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246
0004b60e ??              ???

1:003> knL
 # ChildEBP RetAddr
00 0077f1c4 775c3cf2 0x4b60e
01 0077f1e8 775c3cc4 ntdll!ExecuteHandler2+0x26
02 0077f2b0 775b1546 ntdll!ExecuteHandler+0x24
03 0077f2b0 003aec62 ntdll!KiUserExceptionDispatcher+0x26
04 0077f85c 775973a8 0x3aec62
05 0077f8c8 77597307 ntdll!RtlpCreateNewDirectoryReference+0x7a
06 0077f8e0 775ea714 ntdll!RtlpInitCurrentDir+0x35
07 0077fb40 775976b6 ntdll!LdrpInitializeProcess+0x12c4
08 0077fb98 77597581 ntdll!_LdrpInitialize+0xdf
09 0077fba4 00000000 ntdll!LdrInitializeThunk+0x11

1:003> ub 775973a8 l1
ntdll!RtlpCreateNewDirectoryReference+0x75:
775973a3 e888800100      call    ntdll!NtOpenFile (775af430)

The hooked code is like this:

3:045> g
ModLoad: 77520000 776b9000   ntdll.dll
Breakpoint 1 hit
eax=000000f4 ebx=00000208 ecx=bd60d631 edx=00987c68 esi=00000000 edi=00d7f3a4
eip=010223a0 esp=00d7f1d0 ebp=00d7f23c iopl=0         nv up ei pl nz ac pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000216
firefox!sandbox::TargetNtOpenFile:
010223a0 55              push    ebp
3:045> pc
eax=00000003 ebx=00d7f210 ecx=00d7f4a4 edx=00d7f1ac esi=00d7f130 edi=00d7f3a4
eip=010223fd esp=00d7f118 ebp=00d7f1cc iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000206
firefox!sandbox::TargetNtOpenFile+0x5d:
010223fd ff5508          call    dword ptr [ebp+8]    ss:0023:00d7f1d4=00987c50
3:045> t
eax=00000003 ebx=00d7f210 ecx=00d7f4a4 edx=00d7f1ac esi=00d7f130 edi=00d7f3a4
eip=00987c50 esp=00d7f114 ebp=00d7f1cc iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000206
00987c50 b8f4000000      mov     eax,0F4h
3:045> u .
00987c50 b8f4000000      mov     eax,0F4h
00987c55 e803000000      call    00987c5d
00987c5a c21800          ret     18h

3:045> p
eax=000000f4 ebx=00d7f210 ecx=00d7f4a4 edx=00d7f1ac esi=00d7f130 edi=00d7f3a4
eip=00987c55 esp=00d7f114 ebp=00d7f1cc iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000206
00987c55 e803000000      call    00987c5d

3:045> t
eax=000000f4 ebx=00d7f210 ecx=00d7f4a4 edx=00d7f1ac esi=00d7f130 edi=00d7f3a4
eip=00987c5d esp=00d7f110 ebp=00d7f1cc iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000206
00987c5d 8bd4            mov     edx,esp
3:045> u .
00987c5d 8bd4            mov     edx,esp <<<< these are wrong instructions
00987c5f 0fe5e5          pmulhw  mm4,mm5
00987c62 e5e5            in      eax,0E5h
00987c64 e5e5            in      eax,0E5h
00987c66 e5e5            in      eax,0E5h
00987c68 83ec08          sub     esp,8
00987c6b 52              push    edx
00987c6c 8b54240c        mov     edx,dword ptr [esp+0Ch]
See Also: → 1614885

The root cause is in Chromium sandbox's code. The same crash happens on Chrome/Chromium as well.

I filed https://bugs.chromium.org/p/chromium/issues/detail?id=1053805.

This patch partially implements FileVersionInfoWin and base::FilePath class of
Chromium sandbox so that a coming patch can use base::win::OSInfo::Kernel32BaseVersion().

Cherry-picking Chromium's commit 01c8afd0dc14a1acef383c5f231258d0cfac95e5
to fix the crash caused by Chromium's sandbox code.

The original bug on Chromium side: https://crbug.com/1053805

Depends on D65744

Cherry-picking the following commits from Chromium to keep file_version_info_win.cpp
up-to-date.

  1. Use StringPiece rather than std::string for Version parsing.
    https://source.chromium.org/chromium/chromium/src/+/15a9d1733f4129fb18a7fe57708d351caf42638e

  2. [Cleanup] Un-const the result of base::Version::GetString()
    https://source.chromium.org/chromium/chromium/src/+/fde745d058a8a50019c01c838a7efa5be2f6268c

  3. Export Windows file version as base::Version
    https://source.chromium.org/chromium/chromium/src/+/e93de3a37d21cd2ef61890d8acafb4b3f033781b

  4. Tidy FileVersionInfoWin.
    https://source.chromium.org/chromium/chromium/src/+/4bb23ded3a6612274bb16b347ae7a387ddc51c29

Depends on D65744

Attachment #9131498 - Attachment description: Bug 1615401 - Part 2: Use OSInfo::Kernel32Version() to select a thunk resolver. r=bobowen → Bug 1615401 - Part 3: Use OSInfo::Kernel32Version() to select a thunk resolver. r=bobowen
Pushed by nerli@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/032c00b0ab39
Part 1: Partially implement FileVersionInfoWin to use from OSInfo::Kernel32BaseVersion().  r=bobowen
https://hg.mozilla.org/integration/autoland/rev/dc9d71fb3bac
Part 2: Keep Chromium's file_version_info_win.cpp updated  r=bobowen
https://hg.mozilla.org/integration/autoland/rev/b6a09f304f86
Part 3: Use OSInfo::Kernel32Version() to select a thunk resolver.  r=bobowen
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla75
Regressions: 1620832
Flags: qe-verify+

Reproduced the issue with 74.0b3 (20200214015126) on Windows 10x86 and running Firefox in compatibility mode for Windows 7.
No crashes or functionality issues encountered while running Firefox 75.0b5 (20200317211402) on Windows 10x86 in compatibility mode for Windows 7.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: