1744391 - Uncontrolled Search Path Element via igd10iumd64.dll

Status: RESOLVED WORKSFORME

(Core :: Widget: Win32, defect)

Description

[D4ni31 [:d4ni31]]

Attachment: firefox_report_image.zip

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36

Steps to reproduce:

In FireFox 94.0.2 (Stable) Version, an Uncontrolled Search Path Element (DLL Hijacking) vulnerability exists. The vulnerability occurs during the loading of igd10iumd64.dll. You can see that you are attempting to browse and load that DLL from a directory added to %PATH%.

Actual results:

Typically, you can execute arbitrary code by inserting another malicious DLL in the "\AppData\Local\Microsoft\WindowsApps" folder that can be written by a general user.

Expected results:

DLL load must be loaded from a folder that does not have write permission from the general user. "For example, C:\Windows\System32".

Comment 1

[Toshihito Kikuchi [:toshi]]

Thank you for reporting this! Can you share the stack info of the loading events of searching those paths?

Comment 2

[D4ni31 [:d4ni31]]

This is stack information when calling the DLL. Thanks

0	FLTMGR.SYS	FltDecodeParameters + 0x213c	0xfffff80467b2601c	C:\WINDOWS\System32\drivers\FLTMGR.SYS
1	FLTMGR.SYS	FltDecodeParameters + 0x1d75	0xfffff80467b25c55	C:\WINDOWS\System32\drivers\FLTMGR.SYS
2	FLTMGR.SYS	FltAddOpenReparseEntry + 0x560	0xfffff80467b5c270	C:\WINDOWS\System32\drivers\FLTMGR.SYS
3	ntoskrnl.exe	IofCallDriver + 0x55	0xfffff80462c8f6f5	C:\WINDOWS\system32\ntoskrnl.exe
4	ntoskrnl.exe	IoGetAttachedDevice + 0x194	0xfffff80462c90ce4	C:\WINDOWS\system32\ntoskrnl.exe
5	ntoskrnl.exe	NtDeviceIoControlFile + 0x249d	0xfffff8046307717d	C:\WINDOWS\system32\ntoskrnl.exe
6	ntoskrnl.exe	SeOpenObjectAuditAlarmWithTransaction + 0x58ce	0xfffff80462ff23ee	C:\WINDOWS\system32\ntoskrnl.exe
7	ntoskrnl.exe	ObOpenObjectByNameEx + 0x1fa	0xfffff804630948aa	C:\WINDOWS\system32\ntoskrnl.exe
8	ntoskrnl.exe	NtCreateFile + 0xfe5	0xfffff80463016bd5	C:\WINDOWS\system32\ntoskrnl.exe
9	ntoskrnl.exe	setjmpex + 0x7cc5	0xfffff80462e08cb5	C:\WINDOWS\system32\ntoskrnl.exe
10	ntdll.dll	NtQueryAttributesFile + 0x14	0x7ffc07dcd514	C:\Windows\System32\ntdll.dll
11	ntdll.dll	RtlDosSearchPath_Ustr + 0x64d	0x7ffc07d4a28d	C:\Windows\System32\ntdll.dll
12	ntdll.dll	RtlDosSearchPath_Ustr + 0x478	0x7ffc07d4a0b8	C:\Windows\System32\ntdll.dll
13	KernelBase.dll	PathCchCombineEx + 0xd77	0x7ffc05a28837	C:\Windows\System32\KernelBase.dll
14	KernelBase.dll	LoadLibraryExW + 0xe0	0x7ffc05a2ad60	C:\Windows\System32\KernelBase.dll
15	KernelBase.dll	GetFileVersionInfoSizeExW + 0x3d	0x7ffc05a16c2d	C:\Windows\System32\KernelBase.dll
16	xul.dll	workerlz4_compress + 0x1a97293	0x7ffb8299ac53	C:\Program Files\Mozilla Firefox\xul.dll
17	xul.dll	workerlz4_compress + 0xa32522	0x7ffb81935ee2	C:\Program Files\Mozilla Firefox\xul.dll
18	xul.dll	workerlz4_compress + 0x150eef8	0x7ffb824128b8	C:\Program Files\Mozilla Firefox\xul.dll
19	xul.dll	workerlz4_compress + 0x11f3f49	0x7ffb820f7909	C:\Program Files\Mozilla Firefox\xul.dll
20	xul.dll	workerlz4_compress + 0x11ec473	0x7ffb820efe33	C:\Program Files\Mozilla Firefox\xul.dll
21	xul.dll	XRE_GetBootstrap + 0xa65c0	0x7ffb80b98940	C:\Program Files\Mozilla Firefox\xul.dll
22	xul.dll	workerlz4_compress + 0x12ae743	0x7ffb821b2103	C:\Program Files\Mozilla Firefox\xul.dll
23	xul.dll	workerlz4_compress + 0xa49dd2	0x7ffb8194d792	C:\Program Files\Mozilla Firefox\xul.dll
24	xul.dll	workerlz4_compress + 0xa470ba	0x7ffb8194aa7a	C:\Program Files\Mozilla Firefox\xul.dll
25	xul.dll	workerlz4_compress + 0xa46cb6	0x7ffb8194a676	C:\Program Files\Mozilla Firefox\xul.dll
26	xul.dll	XRE_GetBootstrap + 0xa5c75	0x7ffb80b97ff5	C:\Program Files\Mozilla Firefox\xul.dll
27	xul.dll	workerlz4_compress + 0xd095b3	0x7ffb81c0cf73	C:\Program Files\Mozilla Firefox\xul.dll
28	xul.dll	workerlz4_compress + 0xd0a22c	0x7ffb81c0dbec	C:\Program Files\Mozilla Firefox\xul.dll
29	xul.dll	workerlz4_compress + 0xd59a00	0x7ffb81c5d3c0	C:\Program Files\Mozilla Firefox\xul.dll
30	xul.dll	workerlz4_compress + 0xd77632	0x7ffb81c7aff2	C:\Program Files\Mozilla Firefox\xul.dll
31	xul.dll	workerlz4_compress + 0xd753fa	0x7ffb81c78dba	C:\Program Files\Mozilla Firefox\xul.dll
32	xul.dll	workerlz4_compress + 0x1a85f62	0x7ffb82989922	C:\Program Files\Mozilla Firefox\xul.dll
33	xul.dll	workerlz4_compress + 0x156665e	0x7ffb8246a01e	C:\Program Files\Mozilla Firefox\xul.dll
34	xul.dll	workerlz4_compress + 0x1567d20	0x7ffb8246b6e0	C:\Program Files\Mozilla Firefox\xul.dll
35	xul.dll	workerlz4_compress + 0x124536a	0x7ffb82148d2a	C:\Program Files\Mozilla Firefox\xul.dll
36	xul.dll	workerlz4_compress + 0x16e15fd	0x7ffb825e4fbd	C:\Program Files\Mozilla Firefox\xul.dll
37	xul.dll	soundtouch::SoundTouch::operator= + 0x10e819f	0x7ffb84cd0e3f	C:\Program Files\Mozilla Firefox\xul.dll
38	xul.dll	XRE_GetBootstrap + 0x6ead4	0x7ffb80b60e54	C:\Program Files\Mozilla Firefox\xul.dll
39	xul.dll	XRE_GetBootstrap + 0x852b2	0x7ffb80b77632	C:\Program Files\Mozilla Firefox\xul.dll
40	xul.dll	XRE_GetBootstrap + 0x851b5	0x7ffb80b77535	C:\Program Files\Mozilla Firefox\xul.dll
41	xul.dll	workerlz4_compress + 0x5fda7c	0x7ffb8150143c	C:\Program Files\Mozilla Firefox\xul.dll
42	xul.dll	XRE_GetBootstrap + 0x8216b	0x7ffb80b744eb	C:\Program Files\Mozilla Firefox\xul.dll
43	xul.dll	workerlz4_compress + 0x3be911	0x7ffb812c22d1	C:\Program Files\Mozilla Firefox\xul.dll
44	xul.dll	workerlz4_compress + 0x150ebe1	0x7ffb824125a1	C:\Program Files\Mozilla Firefox\xul.dll
45	xul.dll	workerlz4_compress + 0x11e613e	0x7ffb820e9afe	C:\Program Files\Mozilla Firefox\xul.dll
46	xul.dll	XRE_GetBootstrap + 0x1bf4a	0x7ffb80b0e2ca	C:\Program Files\Mozilla Firefox\xul.dll
47	xul.dll	XRE_GetBootstrap + 0x1beda	0x7ffb80b0e25a	C:\Program Files\Mozilla Firefox\xul.dll
48	xul.dll	XRE_GetBootstrap + 0x80bb9	0x7ffb80b72f39	C:\Program Files\Mozilla Firefox\xul.dll
49	xul.dll	soundtouch::SoundTouch::operator= + 0x1075858	0x7ffb84c5e4f8	C:\Program Files\Mozilla Firefox\xul.dll
50	xul.dll	soundtouch::SoundTouch::operator= + 0x1076f40	0x7ffb84c5fbe0	C:\Program Files\Mozilla Firefox\xul.dll
51	xul.dll	workerlz4_compress + 0x1a89933	0x7ffb8298d2f3	C:\Program Files\Mozilla Firefox\xul.dll
52	firefox.exe	GetNtLoaderAPI + 0x4b14	0x7ff611789ea4	C:\Program Files\Mozilla Firefox\firefox.exe
53	firefox.exe	IsSandboxedProcess + 0x1798	0x7ff61179c018	C:\Program Files\Mozilla Firefox\firefox.exe
54	kernel32.dll	BaseThreadInitThunk + 0x14	0x7ffc06fd7034	C:\Windows\System32\kernel32.dll
55	ntdll.dll	RtlUserThreadStart + 0x21	0x7ffc07d82651	C:\Windows\System32\ntdll.dll

Comment 3

[Toshihito Kikuchi [:toshi]]

Thank you for sharing the stack! This file access happened here, that checks the version of Intel graphics driver. In this case, GetFileVersionInfoSizeExW calls LoadLibraryExW with 0x22 (= LOAD_LIBRARY_AS_IMAGE_RESOURCE | LOAD_LIBRARY_AS_DATAFILE), so no code execution is triggered.

If you symbolicate the stack, it will be something like this.

00 00000023`d97fd268 00007ff9`475c6b6d     KERNELBASE!LoadLibraryExW
01 00000023`d97fd270 00007ff9`15e1ac53     KERNELBASE!GetFileVersionInfoSizeExW+0x3d
02 00000023`d97fd2d0 00007ff9`14db5ee2     xul!gfxWindowsPlatform::GetDLLVersion+0x43
03 00000023`d97fd6f0 00007ff9`158928b8     xul!mozilla::widget::GfxInfo::Init+0xb52
04 00000023`d97fe1a0 00007ff9`15577909     xul!mozilla::xpcom::CreateInstanceImpl+0x1188
05 (Inline Function) --------`--------     xul!mozilla::xpcom::StaticModule::CreateInstance+0x27
06 (Inline Function) --------`--------     xul!`anonymous namespace'::EntryWrapper::CreateInstance+0x30
07 (Inline Function) --------`--------     xul!nsComponentManagerImpl::GetServiceLocked+0x4dc
08 00000023`d97fe220 00007ff9`1556fe33     xul!nsComponentManagerImpl::GetService+0x569
09 (Inline Function) --------`--------     xul!mozilla::xpcom::GetServiceHelper::operator()+0x19
0a 00000023`d97fe3a0 00007ff9`14a952aa     xul!nsCOMPtr_base::assign_from_helper+0x53
0b (Inline Function) --------`--------     xul!nsCOMPtr<nsIGfxInfo>::nsCOMPtr+0xf
0c 00000023`d97fe460 00007ff9`149146ac     xul!mozilla::gfx::GPUParent::RecvInit+0x1aa
0d 00000023`d97fe6f0 00007ff9`158c3ef6     xul!mozilla::gfx::PGPUParent::OnMessageReceived+0xe9c
0e (Inline Function) --------`--------     xul!mozilla::ipc::MessageChannel::DispatchAsyncMessage+0x73
0f 00000023`d97fe850 00007ff9`1589f540     xul!mozilla::ipc::MessageChannel::DispatchMessage+0x3f6

Comment 4

[D4ni31 [:d4ni31]]

The problem seems to be able to trigger Code Execution with DLL Proxy.

Comment 5

[D4ni31 [:d4ni31]]

For DLL Proxy, please refer to the link.

https://kevinalmansa.github.io/application%20security/DLL-Proxying/

Comment 6

[Daniel Veditz [:dveditz]]

Toshihito: I don't believe the directory DoHyun cites should be on our normal DLL load path, so how does it end up used here? Does loading it to check its version run some DLL prolog code or something that would cause the effect claimed in comment 4?

Comment 7

[Toshihito Kikuchi [:toshi]]

I confirmed the search sequence of GetFileVersionInfoW (we call it here) does not respect the process's PreferSystem32Images policy, although MS Docs says this API starts the search sequence as LoadLibrary does. So we do search all paths in the PATH environment variable, but it does not map a module as an executable region nor run any DLL code. I don't see any security risk here.

I think DLL Proxying is a completely different topic from DLL planting. It's a DLL injection technique, not a vulnerability.

Comment 8

[D4ni31 [:d4ni31]]

Hi,

I think DLL proxy is DLL planting technique. I think it's a little different from DLL Injection. DLL injection is forced into the memory space of the running process. The DLL proxy is not forced into the memory space, but links the original DLL to perform the same behavior as the original by bringing in the malicious DLL when the DLL is first executed.

Comment 9

[D4ni31 [:d4ni31]]

For example, attacks using DLL proxy techniques include CVE-2019-14684 (Trend Micro) and CVE-2019-3648 (McAfee).

Comment 10

[:Gijs (he/him)]

Toshi, based on the last few comments, is there something we should address here?

Comment 11

[Toshihito Kikuchi [:toshi]]

(In reply to DoHyun Lee from comment #8)

I think DLL proxy is DLL planting technique. I think it's a little different from DLL Injection. DLL injection is forced into the memory space of the running process. The DLL proxy is not forced into the memory space, but links the original DLL to perform the same behavior as the original by bringing in the malicious DLL when the DLL is first executed.

Ok, I misunderstood dll proxying. I thought it was to modify the mapped image, but I was wrong. Then what is different from DLL planting? Does it bypass the PreferSystem32Images policy in some way? Again, the stack in comment 2 does not execute any code of a module, so it cannot be a target of dll planting.

Comment 12

[D4ni31 [:d4ni31]]

Hi,

I just checked. Code execution is not possible due to the PreferSystem32Images policy.
The case does not seem to be a vulnerability.

Thanks!

Comment 13

[D4ni31 [:d4ni31]]

And one problem is that the PreferSystem32Images mitigation policy was applied to version Windows 10.0.14393. Can you trigger on Windows 7? Can you check?

Comment 14

[Toshihito Kikuchi [:toshi]]

(In reply to DoHyun Lee from comment #13)

And one problem is that the PreferSystem32Images mitigation policy was applied to version Windows 10.0.14393. Can you trigger on Windows 7? Can you check?

The stack in comment 2 is not exploitable regardless of the PreferSystem32Images policy.

For the older platforms where the policy do not exist, we are aware that DLL planting is possible through other modules. To minimize the risk, the binaries should be installed in a trusted directory such as "Program Files". I'm not sure there is anything to prevent it from the application side.

Comment 15

[D4ni31 [:d4ni31]]

Hi,

How about loading the DLL file you want to load only from a subfolder of C:\Windows\System32`?

Comment 16

[Toshihito Kikuchi [:toshi]]

(In reply to DoHyun Lee from comment #15)

How about loading the DLL file you want to load only from a subfolder of C:\Windows\System32`?

When we load a system module at runtime, ideally we should always use LOAD_LIBRARY_SEARCH_SYSTEM32 (or our own helper function LoadLibrarySystem32), but even if we do it, we cannot control the search path when a system module loads another system module without the process-wide policy.

Comment 17

[BugBot [:suhaib / :marco/ :calixte]]

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

For more information, please visit auto_nag documentation.

Comment 18

[Daniel Veditz [:dveditz]]

resolving per comment 12 and related discussion