WiX security releases available (redux)

Usually, announcing a new release of WiX is a happy occasion, with celebrations involving cake and adult beverages. Today, not so much. We are...well, not happy, exactly, perhaps merely resigned...to announce security releases of WiX to address two security vulnerabilities, one in a WiX custom action and one in the Burn bootstrapper engine. FireGiant has fixed the vulnerabilities in new releases of WiX v3, v4, and v5. Read on for details about the vulnerabilities and how to get the latest fixes.

Directory junction and recursion vulnerability

The custom action behind WiX's RemoveFolderEx functionality could allow a standard user to delete protected directories.

RemoveFolderEx deletes an entire directory tree during installation or uninstallation. It does so by recursing every subdirectory starting at a specified directory and adding each subdirectory to the list of directories Windows Installer should delete. If the setup author instructed RemoveFolderEx to delete a per-user folder from a per-machine installer, an attacker could create a directory junction in that per-user folder pointing to a per-machine, protected directory. Windows Installer, when executing the per-machine installer after approval by an administrator, would delete the target of the directory junction.

Mitigation: Directory junctions are now skipped during directory recursion.

Does this apply to me? If you use RemoveFolderEx (from WixUtilExtension in WiX v3 and WixToolset.Util.wixext in WiX v4) in your WiX authoring and are removing a directory tree in a user-writable location, an attacker could use this vulnerability and you should upgrade to the appropriate version of WiX: v3.14.1, v4.0.5, or v5.0.0-rc.2.

If you are a FireGiant support customer, please feel free to contact support for assistance verifying if this vulnerability affects your packages.

Read the security advisory on GitHub.

Elevated bundle temporary directory vulnerability

An attacker running as a standard user could tamper with temporary files created from a bundle launched with elevated privileges.

When bundles are launched with administrator privileges, including when launched from another elevated process, Burn creates temporary working folders in the Windows Temp directory to prevent an attacker running as a standard user from tampering with them. While standard users cannot read files or view directories in the Windows Temp directory, they can use API functions like ReadDirectoryChanges to monitor for file system changes that they would not otherwise be able to read. An attacker could then create malicious DLLs known to be loaded by a particular bundle and they would be running in an already-elevated process.

Malicious processes could similarly attack managed-code custom actions, which also use the Windows Temp directory in some cases.

Mitigation: Bundles built with WiX v4 and v5, launched on Windows 11 from a process running as SYSTEM, use the Windows SystemTemp folder. SystemTemp can be accessed only by SYSTEM processes and is not vulnerable. Additionally, particularly to protect WiX v3 and when running on older operating systems, temporary directories are secured against any access by standard users, so directories created in the Windows Temp directory are no longer writable by standard users.

Does this apply to me? If you ship .exe bundles, this vulnerability applies and you should upgrade to the appropriate version of WiX: v3.14.1, v4.0.5, or v5.0.0-rc.2.

Read the security advisory on GitHub.