1741611 - [Windows] DLL HIjacking (Code Execution) by writing dwmapi.dll into Firefox's installed directory

Status: RESOLVED WONTFIX

(Core :: Widget: Win32, defect)

Description

[Kirtikumar Anandrao Ramchandani]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.69 Safari/537.36/8mqEzXuL-46

Steps to reproduce:

1. Copy the DLL to the location: C:\Program Files (x86)\Mozilla Firefox

Actual results:

The browser will crash but it will pop calc

Expected results:

It should have checked DLL like Edge does.

Comment 1

[Kirtikumar Anandrao Ramchandani]

Crash uploaded: https://crash-stats.mozilla.org/report/index/878fde3c-0b05-475a-8ec1-a31e70211117

Comment 2

[Kirtikumar Anandrao Ramchandani]

Attachment: Firefox issue.mp4

Output of windbg:

Microsoft (R) Windows Debugger Version 10.0.22415.1003 X86
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine: C:\Program Files (x86)\Mozilla Firefox\firefox.exe
Error: Change all symbol paths attempts to access 'C:\MoreSymbols' failed: 0x2 - The system cannot find the file specified.

************* Path validation summary **************
Response Time (ms) Location
Deferred srv*
Error C:\MoreSymbols
Symbol search path is: srv*;C:\MoreSymbols
Executable search path is:
ModLoad: 00c60000 00ce6000 firefox.exe
ModLoad: 77bf0000 77d93000 ntdll.dll
ModLoad: 76a00000 76af0000 C:\WINDOWS\SysWOW64\KERNEL32.DLL
ModLoad: 76f70000 77184000 C:\WINDOWS\SysWOW64\KERNELBASE.dll
ModLoad: 74330000 743e5000 C:\WINDOWS\SysWOW64\Scdetour.dll
ModLoad: 77420000 775c0000 C:\WINDOWS\SysWOW64\USER32.dll
ModLoad: 75e00000 75e18000 C:\WINDOWS\SysWOW64\win32u.dll
ModLoad: 766f0000 76714000 C:\WINDOWS\SysWOW64\GDI32.dll
ModLoad: 75bd0000 75cac000 C:\WINDOWS\SysWOW64\gdi32full.dll
ModLoad: 76800000 7687b000 C:\WINDOWS\SysWOW64\msvcp_win.dll
ModLoad: 77250000 77370000 C:\WINDOWS\SysWOW64\ucrtbase.dll
ModLoad: 76bf0000 76c6a000 C:\WINDOWS\SysWOW64\ADVAPI32.dll
ModLoad: 75d40000 75dff000 C:\WINDOWS\SysWOW64\msvcrt.dll
ModLoad: 76880000 768f5000 C:\WINDOWS\SysWOW64\sechost.dll
ModLoad: 77190000 7724f000 C:\WINDOWS\SysWOW64\RPCRT4.dll
ModLoad: 742c0000 742d3000 C:\Program Files (x86)\Mozilla Firefox\VCRUNTIME140.dll
ModLoad: 73e30000 73edb000 C:\Program Files (x86)\Mozilla Firefox\mozglue.dll
ModLoad: 73c20000 73c8f000 C:\Program Files (x86)\Mozilla Firefox\MSVCP140.dll
ModLoad: 75020000 7502a000 C:\WINDOWS\SysWOW64\CRYPTBASE.DLL
ModLoad: 76af0000 76bea000 C:\WINDOWS\SysWOW64\CRYPT32.dll
ModLoad: 76d60000 76da7000 C:\WINDOWS\SysWOW64\WINTRUST.dll
ModLoad: 746c0000 74848000 C:\WINDOWS\SysWOW64\dbghelp.dll
ModLoad: 752e0000 752e8000 C:\WINDOWS\SysWOW64\VERSION.dll
(4408.3d34): Break instruction exception - code 80000003 (first chance)
eax=00000000 ebx=00000000 ecx=d69d0000 edx=00000000 esi=77c02054 edi=77c0261c
eip=77ca1ba2 esp=04eaf604 ebp=04eaf630 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
ntdll!LdrpDoDebuggerBreak+0x2b:
77ca1ba2 cc int 3
0:000> g
ModLoad: 76550000 76575000 C:\WINDOWS\SysWOW64\IMM32.DLL
ModLoad: 75a60000 75a6e000 C:\WINDOWS\SysWOW64\MSASN1.dll
ModLoad: 76260000 762bf000 C:\WINDOWS\SysWOW64\bcryptPrimitives.dll
ModLoad: 762c0000 76541000 C:\WINDOWS\SysWOW64\combase.dll
ModLoad: 750b0000 750bf000 C:\WINDOWS\SysWOW64\kernel.appcore.dll
ModLoad: 75030000 750a4000 C:\WINDOWS\SysWOW64\uxtheme.dll
ModLoad: 74850000 74879000 C:\WINDOWS\SysWOW64\ntmarta.dll
ModLoad: 75b30000 75bc6000 C:\WINDOWS\SysWOW64\OLEAUT32.dll
ModLoad: 77620000 77bd3000 C:\WINDOWS\SysWOW64\shell32.DLL
ModLoad: 75450000 75a58000 C:\WINDOWS\SysWOW64\windows.storage.dll
ModLoad: 75420000 75445000 C:\WINDOWS\SysWOW64\Wldp.dll
ModLoad: 75cb0000 75d37000 C:\WINDOWS\SysWOW64\SHCORE.dll
ModLoad: 76ec0000 76f05000 C:\WINDOWS\SysWOW64\shlwapi.dll
ModLoad: 76910000 769f3000 C:\WINDOWS\SysWOW64\ole32.DLL
ModLoad: 07000000 070ab000 mozglue.dll
ModLoad: 72730000 72925000 nss3.dll
ModLoad: 72730000 72925000 C:\Program Files (x86)\Mozilla Firefox\nss3.dll
ModLoad: 73e00000 73e28000 C:\WINDOWS\SysWOW64\WINMM.dll
ModLoad: 74d60000 74d68000 C:\WINDOWS\SysWOW64\WSOCK32.dll
ModLoad: 75ac0000 75b23000 C:\WINDOWS\SysWOW64\WS2_32.dll
ModLoad: 748f0000 748fc000 lgpllibs.dll
ModLoad: 748f0000 748fc000 C:\Program Files (x86)\Mozilla Firefox\lgpllibs.dll
ModLoad: 5cab0000 6307c000 xul.dll
ModLoad: 5cab0000 6307c000 C:\Program Files (x86)\Mozilla Firefox\xul.dll
ModLoad: 76d00000 76d19000 C:\WINDOWS\SysWOW64\bcrypt.dll
ModLoad: 738a0000 73962000 C:\WINDOWS\SysWOW64\PROPSYS.dll
ModLoad: 74890000 74896000 C:\WINDOWS\SysWOW64\KBDUS.DLL
ModLoad: 75ab0000 75ab6000 C:\WINDOWS\SysWOW64\psapi.dll
ModLoad: 74690000 746b6000 C:\WINDOWS\SysWOW64\dbgcore.DLL
ModLoad: 68570000 68780000 C:\WINDOWS\SysWOW64\dwrite.dll
ModLoad: 740f0000 74108000 C:\WINDOWS\SysWOW64\profapi.dll
ModLoad: 76c80000 76cfe000 C:\WINDOWS\SysWOW64\clbcatq.dll
ModLoad: 73de0000 73df1000 C:\WINDOWS\SysWOW64\napinsp.dll
ModLoad: 73a60000 73ac6000 C:\WINDOWS\SysWOW64\webauthn.dll
ModLoad: 73880000 73896000 C:\WINDOWS\SysWOW64\pnrpnsp.dll
ModLoad: 72710000 72726000 C:\WINDOWS\SysWOW64\NLAapi.dll
ModLoad: 71cd0000 71d02000 C:\WINDOWS\SysWOW64\IPHLPAPI.DLL
ModLoad: 73da0000 73dd1000 C:\WINDOWS\SysWOW64\netprofm.dll
ModLoad: 74890000 748a0000 C:\WINDOWS\SysWOW64\wshbth.dll
ModLoad: 73980000 739b2000 DataExchange.dll
ModLoad: 72540000 726cf000 twinapi.appcore.dll
ModLoad: 714f0000 71542000 C:\WINDOWS\SysWOW64\mswsock.dll
ModLoad: 67d60000 67de2000 TWINAPI.dll
ModLoad: 71d10000 71da1000 C:\WINDOWS\SysWOW64\DNSAPI.dll
ModLoad: 71330000 714d9000 EXPLORERFRAME.dll
ModLoad: 76900000 76907000 C:\WINDOWS\SysWOW64\NSI.dll
ModLoad: 73c90000 73d6b000 WinTypes.dll
ModLoad: 73d70000 73d7e000 C:\WINDOWS\SysWOW64\winrnr.dll
ModLoad: 748e0000 748ea000 C:\WINDOWS\SysWOW64\npmproxy.dll
ModLoad: 714e0000 714e8000 C:\WINDOWS\SysWOW64\WINNSI.DLL
ModLoad: 667b0000 667c4000 C:\WINDOWS\SysWOW64\dhcpcsvc6.DLL
ModLoad: 66790000 667a6000 C:\WINDOWS\SysWOW64\dhcpcsvc.DLL
ModLoad: 67d60000 67de2000 C:\WINDOWS\SysWOW64\twinapi.dll
ModLoad: 76720000 767f3000 C:\WINDOWS\SysWOW64\MSCTF.dll
ModLoad: 76d20000 76d5b000 C:\WINDOWS\SysWOW64\cfgmgr32.dll
ModLoad: 123d0000 123d8000 C:\Program Files (x86)\Mozilla Firefox\dwmapi.dll
(4408.3d34): Unknown exception - code c06d007e (first chance)
(4408.3d34): Unknown exception - code c06d007e (!!! second chance !!!)
eax=04eaddc0 ebx=00000000 ecx=00000001 edx=00000000 esi=00000000 edi=00000000
eip=7709b502 esp=04eaddc0 ebp=04eade18 iopl=0 nv up ei pl nz ac pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000216
KERNELBASE!RaiseException+0x62:
7709b502 8b4c2454 mov ecx,dword ptr [esp+54h] ss:002b:04eade14=1ba8eb1c
0:000> g
(4408.3d34): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000000 ebx=612237d6 ecx=06f91c00 edx=00000000 esi=06f91c00 edi=04eade9c
eip=00000000 esp=04eade88 ebp=04eadfc8 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246
00000000 ?? ???
0:000> k

ChildEBP RetAddr

WARNING: Frame IP not in any known module. Following frames may be wrong.
00 04eade84 5d7cbe42 0x0
01 04eadfc8 5d7cb2f6 xul!workerlz4_compress+0x9720f2
02 04eae138 5cbc1e60 xul!workerlz4_compress+0x9715a6
03 04eae1a0 5da8c084 xul!XRE_GetBootstrap+0x10fc60
04 04eae258 5da8cb95 xul!workerlz4_compress+0xc32334
05 04eae2b4 5dad4c84 xul!workerlz4_compress+0xc32e45
06 04eae300 5daf0fb8 xul!workerlz4_compress+0xc7af34
07 04eae648 5daef18b xul!workerlz4_compress+0xc97268
08 04eae69c 5e74d367 xul!workerlz4_compress+0xc9543b
09 04eae6d8 5e272bee xul!workerlz4_compress+0x18f3617
0a 04eae8a0 5e2741ca xul!workerlz4_compress+0x1418e9e
0b 04eae92c 5e3eb45e xul!workerlz4_compress+0x141a47a
0c 04eaec98 5e3dfbb8 xul!workerlz4_compress+0x159170e
0d 04eaed10 5cb0adb1 xul!workerlz4_compress+0x1585e68
0e 04eaed60 5cb1c6ce xul!XRE_GetBootstrap+0x58bb1
0f 04eaedb8 5cb1c5f7 xul!XRE_GetBootstrap+0x6a4ce
10 04eaee1c 5d3f57d8 xul!XRE_GetBootstrap+0x6a3f7
11 04eaf000 5cb1991d xul!workerlz4_compress+0x59ba88
12 04eaf1a4 5d1de8ad xul!XRE_GetBootstrap+0x6771d
13 04eaf244 5e221e64 xul!workerlz4_compress+0x384b5d
14 04eaf270 5e228d9e xul!workerlz4_compress+0x13c8114
15 04eaf388 5df3f001 xul!workerlz4_compress+0x13cf04e
16 04eaf3d8 5cac7c70 xul!workerlz4_compress+0x10e52b1
17 04eaf3f8 5cac7c05 xul!XRE_GetBootstrap+0x15a70
18 04eaf414 5cb18825 xul!XRE_GetBootstrap+0x15a05
19 04eaf4b8 607a9ead xul!XRE_GetBootstrap+0x66625
1a 04eaf750 607ab3e8 xul!soundtouch::SoundTouch::operator=+0xf001fd
1b 04eaf7a0 5e74fff6 xul!soundtouch::SoundTouch::operator=+0xf01738
1c 04eaf870 607b0401 xul!workerlz4_compress+0x18f62a6
1d 04eaf884 00c67848 xul!soundtouch::SoundTouch::operator=+0xf06751
1e 04eafb0c 00c771dc firefox!GetNtLoaderAPI+0xb98
1f 04eafb54 76a1fa29 firefox!IsSandboxedProcess+0x192c
20 04eafb64 77c57a9e KERNEL32!BaseThreadInitThunk+0x19
21 04eafbc0 77c57a6e ntdll!__RtlUserThreadStart+0x2f
22 04eafbd0 00000000 ntdll!_RtlUserThreadStart+0x1b

Comment 3

[Kirtikumar Anandrao Ramchandani]

While digging up more, the issue happened while loading the DLL: ModLoad: 123d0000 123d8000 C:\Program Files (x86)\Mozilla Firefox\dwmapi.dll (4408.3d34): Unknown exception - code c06d007e (first chance) can be seen from the windbg. Moving ahead, the root cause lies here: https://searchfox.org/mozilla-central/source/widget/windows/nsUXThemeData.cpp

And the issue was previously patched: https://bugzilla.mozilla.org/show_bug.cgi?id=579593
Unfortunately, this DLL is being shared with gaming files and few more softwares. Assuming that the issue is being exploited in-the-wild as it is being shared. I got this case from my friend while he was downloading crack game.

Adding @Daniel into the report as he analyzes the case well and has good co-operation with the analyst moreover, he has approved patch in that case. @Daniel, any possibility, you can help in triaging this case?

Comment 4

[Sergey Galich [:serg]]

(In reply to Kirtikumar Anandrao Ramchandani from comment #0)

Steps to reproduce:

1. Copy the DLL to the location: C:\Program Files (x86)\Mozilla Firefox

:Kirtikumar Anandrao Ramchandani thanks for bringing this up!

Note that when attacker can copy a file to that location (admin level), they are most likely have permissions to replace firefox.exe itself.

With that being said, we still should check that we call SetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_SYSTEM32) early and that we load app libraries using full path or via LoadLibraryExW(name, NULL, LOAD_LIBRARY_SEARCH_APPLICATION_DIR).

Comment 5

[Kirtikumar Anandrao Ramchandani]

(In reply to Sergey Galich from comment #4)

Note that when attacker can copy a file to that location (admin level), they are most likely have permissions to replace firefox.exe itself.

Yes. But it would be even more interesting when the application (or its setup) makes the directory world-writable. DLL hijacking is used quite often to escalate privileges. But it can, of course, also get used with phishing to gain access to a user's PC. Or to get access to another user's account, once they log in an use the hijacked software.

With that being said, we still should check that we call SetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_SYSTEM32) early and that we load app libraries using full path or via LoadLibraryExW(name, NULL, LOAD_LIBRARY_SEARCH_APPLICATION_DIR).

Correct. If it is world writable, then, you should definitely implement DLL signing and verify the DLLs' signatures, before loading them.

I haven't gone deeper into this as I am trying to look into bug 1740725.

Comment 6

[:Gijs (he/him)]

(In reply to Kirtikumar Anandrao Ramchandani from comment #3)

Moving ahead, the root cause lies here: https://searchfox.org/mozilla-central/source/widget/windows/nsUXThemeData.cpp

There's no loadlibrary call there, afaict? It's not clear to me why you believe this would be the cause. Also, the error you cite in comment #3 being ERROR_MOD_NOT_FOUND suggests we're not actually loading the library you put in the directory, possibly because we use PROCESS_MITIGATION_IMAGE_LOAD_POLICY anyway (bug 1460426).

Toshi, can you take a look or redirect?

Comment 7

[:Gijs (he/him)]

For more context, bug 1696871 was wontfixed but bug 1644954 got fixed.

Comment 8

[Kirtikumar Anandrao Ramchandani]

(In reply to :Gijs (he/him) from comment #6)

There's no loadlibrary call there, afaict?

There is none.

It's not clear to me why you believe this would be the cause. Also, the error you cite in comment #3 being ERROR_MOD_NOT_FOUND suggests we're not actually loading the library you put in the directory, possibly because we use PROCESS_MITIGATION_IMAGE_LOAD_POLICY anyway (bug 1460426).

Because this is the same issue as bug 579593 which is introduced again.

Comment 9

[Kirtikumar Anandrao Ramchandani]

(In reply to :Gijs (he/him) from comment #7)

For more context, bug 1696871 was wontfixed but bug 1644954 got fixed.

Thanks for linking these two cases. The bug 579593 was patched from where this "dwmapi.dll" is being shared and is also being used to exploit. This is weird because 579593 is also an issue where the DLL is loaded in the process of initialization.

In bug 1696871, @Toshi has said the same what Sergey did in comment 4 of this case:

Thank you for looping me in. It's a technique known as "Dll planting". Here's an article written by MSRC. If an attacker already has permission to put a file in the install directory, they even replace firefox.exe itself, and we cannot prevent that by our code. I cannot think of any mitigation for this attack from our side.

Comment 8 of daniel gives helpful information from the case you attached i.e. bug 1696871, which tells the reason why it can't be patched but bug 579593 was. Other DLL checks are passed by firefox when checking it for a few more cases.

If we call that such issues can't be fixed how the issue 579593 was marked patch and a patch was also introduced for it? O.o

I didn't find any specific call for that DLL neither call for a loadlibrary there, correct @Gijs. Probably it will be in some import tables and maybe due to that, it was automatically loaded when the application started?

Comment 10

[:Gijs (he/him)]

(In reply to Kirtikumar Anandrao Ramchandani from comment #9)

(In reply to :Gijs (he/him) from comment #7)

For more context, bug 1696871 was wontfixed but bug 1644954 got fixed.

Thanks for linking these two cases. The bug 579593 was patched from where this "dwmapi.dll" is being shared

That was 11 years ago, the code has changed a lot, and there is no longer a LoadLibrary call for this dll, unlike 11 years ago. I don't have any other information here nor time to investigate further; Toshi, Molly and Dan can decide what to do here.

Comment 11

[Molly Howell (she/her) (mostly inactive)]

I concur with the assessment in comment 4 that this is highly unlikely to be an issue. We don't do anything to manipulate the permissions on our own installation directory, we just let them inherit, so the user basically sets their own risk level based on where they put the installation (the default being Program Files), and there isn't much we can do to affect that. Since privilege escalation was mentioned, it's probably also worth noting that, in my opinion, this is unlikely to be useful for that either; the browser goes out of its way to avoid running under a privileged token (this is assuming UAC is active, of course), and that check happens well before dwmapi.dll would ever be loaded.

Also, note that I expect we'll be using delay loading for this DLL (as with many OS DLLs), which means there won't necessarily be a LoadLibrary call visible in our code, because those calls are being inserted by the compiler at the points where an import from that DLL is called. And in fact one major reason for doing that is to avoid this specific kind of problem, because removing those DLLs from our static import table allows us to configure our DLL search path before they've been loaded.

For what it's worth, I don't seem able to reproduce any attempt to actually load the DLL from that path. The only attempted access that I'm seeing to dwmapi.dll within the application directory is coming from here, where we're just trying to resolve the path to it after its already been loaded.

Comment 12

[Sergey Galich [:serg]]

There is 3rd party libwebrtc that loads this DLL using LoadLibraryW(L"dwmapi.dll") call. If this happens before other attempts, DLL can be loaded from app folder.

Another attempt to load it from the same libwebrtc.

Comment 13

[Kirtikumar Anandrao Ramchandani]

(In reply to Sergey Galich from comment #12)

There is 3rd party libwebrtc that loads this DLL using LoadLibraryW(L"dwmapi.dll") call. If this happens before other attempts, DLL can be loaded from app folder.

Thanks for the information!
The same is also used by Chrome here. But the issue isn't reproducible in Chrome.

Another attempt to load it from the same libwebrtc.

This is also in the Chromium

Let me know if you succeed in reproducing the issue in Chrome because I made multiple attempts but the Chrome seems to be fine.

Comment 14

[Toshihito Kikuchi [:toshi]]

For the general dll planting risk, my stance is not changed. As this comment in bug 1696871 says, however, if putting a new file could be easier than replacing an existing file, there are some actionable items on our side.

To understand the potential targets, I traced Firefox startup with Procmon to see what modules Firefox tries to load from its installation directory and fails with NAME NOT FOUND. dwmapi.dll was not accessed during startup, but many other modules, such as version.dll, dbghelp.dll, etc., were. I also confirmed DLL planting through a fake dll actually worked. Instead of dwmapi.dll, I picked version.dll and cryptbase.dll, and both cases easily worked (Firefox loaded my fake dll and launched a new process via DllMain).

For version.dll, our problem is not in firefox.exe but in mozglue.dll, which does not delay-load version.dll. Just adding version.dll in DELAYLOAD_DLLS of mozglue.dll solved the version.dll issue. Firefox.exe has already delayloaded version.dll, so not doing so in mozglue.dll makes no sense.

The next step would be to understand how (by who) each of the potential targets is loaded from the install directory. Moving to delayload might contribute to startup performance improvement.

(In reply to Kirtikumar Anandrao Ramchandani from comment #13)

Let me know if you succeed in reproducing the issue in Chrome because I made multiple attempts but the Chrome seems to be fine.

Please try version.dll. Chrome also loaded the fake version.dll I created for Firefox from Chrome's install directory (e.g. C:\Program Files (x86)\Google\Chrome\Application).

Comment 15

[Toshihito Kikuchi [:toshi]]

On Windows 10, we enable the PreferSystem32Images policy, so the system DLLs, including dwmapi.dll, are loaded from the system directory before searching the current directory. Currently Firefox delayloads dwmapi.dll from the system directory, and I don't see any problem there. Even if PreferSystem32Images is enabled, however, it seems that some modules are still loaded from the current directory. I'll file a new bug for that.

Comment 16

[Kirtikumar Anandrao Ramchandani]

Access denied.

Comment 17

[Sergey Galich [:serg]]

Note: to quickly test DLL hijacking rename any DLL to version.dll (or whatever system name you want to test). Firefox will start crashing because entry points are missing.

Another finding is that 7zstub adds LOAD_LIBRARY_SEARCH_USER_DIRS to LOAD_LIBRARY_SEARCH_SYSTEM32. If I understand it correctly, this can affect our installer that is typically running from Downloads folder.

:toshi can I get CC on bug 1742692 please?

Comment 18

[Molly Howell (she/her) (mostly inactive)]

(In reply to Sergey Galich from comment #17)

Another finding is that 7zstub adds LOAD_LIBRARY_SEARCH_USER_DIRS to LOAD_LIBRARY_SEARCH_SYSTEM32. If I understand it correctly, this can affect our installer that is typically running from Downloads folder.

Our build does not call that LoadSecurityDlls function.

Comment 19

[Sergey Galich [:serg]]

(In reply to Molly Howell (she/her) [:mhowell] from comment #18)

Our build does not call that LoadSecurityDlls function.

Thanks, that's good to know!

Comment 20

[Toshihito Kikuchi [:toshi]]

(In reply to Sergey Galich from comment #17)

Note: to quickly test DLL hijacking rename any DLL to version.dll (or whatever system name you want to test). Firefox will start crashing because entry points are missing.

For a module to be loaded through static dependency, all imported functions need to be resolved i.e. they need to be exported. A fake version.dll needs to export GetFileVersionInfoSizeW, GetFileVersionInfoW, and VerQueryValueW. The easiest choice is cryptbase.dll, which needs to export SystemFunction036 only.

Comment 21

[Sergey Galich [:serg]]

(In reply to Toshihito Kikuchi [:toshi] from comment #20)

(In reply to Sergey Galich from comment #17)

Note: to quickly test DLL hijacking rename any DLL to version.dll (or whatever system name you want to test). Firefox will start crashing because entry points are missing.

For a module to be loaded through static dependency, all imported functions need to be resolved i.e. they need to be exported. A fake version.dll needs to export GetFileVersionInfoSizeW, GetFileVersionInfoW, and VerQueryValueW. The easiest choice is cryptbase.dll, which needs to export SystemFunction036 only.

That's true, fake DLL will not be loaded, but it crashes loader (expected exports are not there).

For example, with dwmapi.dll it doesn't crash, that tells me system didn't try to load my fake.
For version.dll it does crash, so system tries to load it.
It can be used as a quick test before making real fake with expected exports.

Comment 22

[Daniel Veditz [:dveditz]]

And the issue was previously patched: bug 579593

The significant difference between that bug and this one is that in the old bug the library could be loaded from the "current" directory, which could be any document-containing folder if you clicked on a document to launch Firefox as the default browser. Since then we use a more restricted .dll loading search path.

Comment 23

[Kirtikumar Anandrao Ramchandani]

Do we have any status update on this case? If yes, can you please update if it is confirmed and other details? Thanks!

Comment 24

[Toshihito Kikuchi [:toshi]]

I didn't find any risk in loading dwmapi.dll. We use PreferSystem32Images on Win10. On the older platforms, I don't think there is a safe way to prevent this. Therefore I think we can resolve this as wontfix. Daniel, what do you think?

Comment 25

[Daniel Veditz [:dveditz]]

Expected results: It should have checked DLL like Edge does.

Edge comes from Microsoft and therefore has a head start taking advantage of a Windows 10 mitigation that only allows dynamic loading of Microsoft-signed libraries. We'd like to do the same but it will take a lot of reworking (see for example bug 1409569 and talked about in some others). Since this attack requires that the local system be compromised by an entity with the ability to modify the Firefox install directory the security gain compared to the amount of effort has kept this very low on the priority list. Unlike, say, moving functionality into different special-purpose processes that can have stricter sandboxing rules applied to protect against remote attacks.

(In reply to Toshihito Kikuchi [:toshi] from comment #24)

I didn't find any risk in loading dwmapi.dll. We use PreferSystem32Images on Win10. On the older platforms, I don't think there is a safe way to prevent this. Therefore I think we can resolve this as wontfix. Daniel, what do you think?

I agree

Comment 26

[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 27

[Toshihito Kikuchi [:toshi]]

Resolving this as WontFix based on the conclusion in comment 24 and comment 25.