Mozilla Firefox Windows MSI Installer Elevation of Privileges through DLL Hijacking
Categories
(Firefox :: Installer, defect)
Tracking
()
People
(Reporter: s3nds3c, Unassigned)
Details
(Keywords: csectype-priv-escalation, reporter-external, sec-moderate, Whiteboard: [client-bounty-form])
Attachments
(1 file)
|
543.55 KB,
application/x-7z-compressed
|
Details |
The Mozilla Firefox Windows MSI installer package is prone to an elevation of privileges vulnerability. This especially poses a risk in a corporate environment where users normally don’t have administrative privileges, and client software is distributed using centrally managed software distribution tools running with elevated privileges like SYSTEM. This mostly affects Windows clients, but can also affect Windows servers, e.g. if used as a Terminalserver for multiple users.
This was tested with latest 64 bit version 'Firefox Setup 129.0.msi' downloaded from https://download-installer.cdn.mozilla.net/pub/firefox/releases/129.0/win64/en-US/Firefox%20Setup%20129.0.msi on a fully patched Windows 11 64 bit system.
When the MSI installer is executed in NT AUTHORITY/SYSTEM context - as known to be done through software distribution solutions in corporate environments - multiple temporary files and folders are created within C:\Windows\Temp. In this folder, any local non-admin user is allowed to create arbitrary folders and files. While most of the files and folders created by the installer are write-protected, a dynamically created folder with the name C:\Windows\Temp\7zSxxx, where xxx is a randomly created 8 digit hex number, just inherits its folder permissions from C:\Windows\Temp which in turn allow a non-admin user to write into it. Within this temporary folder, the installer copies all files and folders in C:\Windows\Temp\7zSxxx\core* to the firefox program directory C:\Program Files\Mozilla Firefox.
It was found that when a library called AccessibleHandler.dll is stored in C:\Windows\Temp\7zSxxx\core\ and in turn copied to C:\Program Files\Mozilla Firefox\ by the installer process setup.exe, it is registered by regsvr32.exe executed through setup.exe. This can be abused for elevation of privileges.
Exploit Description
Although the temporary folder is created with a random name which cannot be predicted, it can be easily found by calling the Windows API function ReadDirectoryChangesW which provides the name of a newly created directory or file of a given parent folder (see https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-readdirectorychangesw).
A non-admin user can therefor wait for files being created in a folder below C:\Windows\Temp with the name starting with "7zS", copy a prepared linrary to C:\Windows\Temp\7zSxxx\core\AccessibleHandler.dll and wait for the DLL being copied to C:\Program Files\Mozilla Firefox\ and in turn loaded, executing the malicious injected DLL.
In my PoC I used a DLL which opens a Windows command window in SYSTEM context. This DLL was borrowed from the sub project SystemCmdLauncher of FilesystemEoPs (see https://github.com/thezdi/PoC/tree/main/FilesystemEoPs/SystemCmdLauncher).
Furthermore, I created a little exploit which waits for the creation of the temporary directory as well as copying the prepared DLL to it.
You can find both projects as source code as well as already compiled as 64 bit binaries attached for your convenience.
Steps to reproduce
-
Optionally compile both projects.
-
Copy GenericDllEoP.exe and SystemCmdLauncher.dll to a new folder (I use C:\temp\FFEoP).
-
Open a Windows command prompt (cmd.exe) as the non-admin user and run GenericDllEoP.exe with the following commandline:
GenericDllEop.exe /source SystemCmdLauncher.dll /destFile AccessibleHandler.dll /findFileName AccessibleMarshal.dllPlease note that the parameter /findFileName uses a file named AccessibleMarshal.dll to be found. This file is created within C:\Windows\Temp\7zSxxx\core\ by the installer before setup.exe is started. It is simply used to get the correct folder name and is cut from the path to get the core folder. The exploit then copies our prepared DLL into it with the expected name.
-
When the installation is now triggered, e.g. by the corporate software distribution, the user is provided a SYSTEM shell after a short time. To mimic a corporate software management solution, open an elevated command prompt with SYSTEM rights, e.g. by using Sysinternals "psexec -s cmd.exe".
For your reference also find a screencast of a successful exploit attached (PoC-exploit.mkv).
Conclusion
I'm assuming that there's some kind of 7zip compressed data used in the installer which insecurly creates a temporary folder. This should be avoided by not inheriting frolder permissions from the parent directory but setting the same restriction as done for other temporary folders used by the installer.
Suggested CVSS 3.1 Base Score: 7.8 high, https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Regards,
Sandro
Updated•1 year ago
|
Comment 1•1 year ago
|
||
I think I'd like to wait for a second opinion before doing anything with this bug, but this looks to me like a duplicate of Bug 1269142.
Comment 2•1 year ago
|
||
I'll give it the same rating as that other bug for now.
Comment 3•1 year ago
|
||
Nicholas can you help with setting Priority and Severity for this bug.
Comment 4•1 year ago
|
||
Agreed that this looks like a dupe.
NI :bytesized in case you wanted a more thorough check from someone more familiar with this area, please NI them to consider reopening.
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Description
•