WiX v3.10.2 is an important security release of WiX. We encourage all users of WiX to upgrade to WiX v3.10.2.

All supported versions of Windows (in addition to the unsupported Windows XP) suffer from a vulnerability known as DLL hijacking. In DLL hijacking, malware delivered next to an executable—including Burn bundles—is loaded when a user runs the executable. This is especially problematic for installers, which are typically downloaded to a Downloads folder along with other downloaded files. A website that delivers malware can, depending on your browser and its settings, automatically download a DLL to your Downloads folder. If the DLL is named the same as a system DLL that your bundle loads, Windows loads and executes the malware in the Downloads folder instead of the DLL in the Windows system folder.

Burn bundles do not request elevation when they're launched, so the malware does not get elevated privileges. (Note that this is a default: Some developers have replaced the Burn manifest with one that requests elevation at launch. In that case, malware loaded through DLL hijacking would get elevated privileges.) However, even with just the user's privileges and network permissions, malware can do plenty of damage.

Note that MSI packages and patches are not affected by this Windows vulnerability. They are executed by the Windows Installer service which lives in the Windows system folder and therefore isn't vulnerable to DLL hijacking like downloaded executables.

Download

Download WiX v3.10.2 here.

History

A security researcher reported a related but more narrowly-scoped Windows vulnerability exposed by Burn bundles in November. We investigated and agreed with the security researcher's results and prepared a mitigation in Burn. Because the vulnerability itself was in Windows, we contacted the Microsoft Security Response Center to report the issue and coordinate disclosure. MSRC requested that we delay disclosure until this month's Patch Tuesday. During that wait, we continued our investigation and concluded that DLL hijacking was a more general vulnerability to which Burn was also susceptible.

Because of the seriousness of the vulnerability and its ability to be exploited with Burn, FireGiant committed resources to developing mitigations in Burn that we could release as soon as possible.

Mitigations

Technical details about the mitigations are available in the WiX Improvement Proposal that FireGiant submitted. We also reviewed the code changes in the "live pull request review" from this week's WiX online meeting. FireGiant CEO and co-founder Rob Mensching (one of the aforementioned FireGiant resources) has also promised to go into deeper technical detail about the code changes on his personal blog.

Breaking changes

There are two breaking changes due to this security fix:

  • A bundle cannot be named Setup.exe. When an executable is named Setup.exe, Windows loads additional DLLs in an insecure manner. To prevent such a guaranteed vulnerability, Light.exe now yields an error if the bundle output is named Setup.exe. As Setup.exe might be a common file name, this breaking change is especially annoying. Unfortunately, Windows loads the additional DLLs in a way that Burn code cannot mitigate.

  • The process that loads the bootstrapper application is no longer the process the user started. Attempts to use ::GetModuleFileName to locate the source media (i.e., with loose files next to the bundle .exe) will fail. A workaround is to use the new WixBundleSourceProcessPath and WixBundleSourceProcessFolder variables to find the original process. In general, this shouldn't be a serious problem—bootstrapper applications can already carry all the files they need using Payload elements.

Acknowledgment

We were first alerted to a Windows vulnerability with DLL hijacking of FEClient.dll by Stefan Kanthak.