CVE-2024-29187: WiX Toolset Privilege Escalation Flaw

CVE-2024-29187 Overview

CVE-2024-29187 is a local privilege escalation vulnerability affecting the WiX toolset, a widely-used development framework that enables developers to create Windows Installer packages. The vulnerability exists in the Burn bootstrapper engine, which is responsible for managing bundle installations. When a bundle executes under the SYSTEM user context, the Burn engine utilizes the GetTempPathW Windows API function to determine the temporary file location, which defaults to C:\Windows\Temp. This directory has insecure permissions that allow standard users to write files, creating an opportunity for binary hijacking attacks that can result in elevation of privileges.

Critical Impact

Standard users can hijack binaries dropped by the Burn engine in the insecure temp directory before they are loaded, resulting in local privilege escalation to SYSTEM level access.

Affected Products

• WiX toolset versions prior to 3.14.1
• WiX toolset versions 4.x prior to 4.0.5
• Applications using the Burn bootstrapper engine from affected WiX versions

Discovery Timeline

• 2024-03-24 - CVE-2024-29187 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2024-29187

Vulnerability Analysis

This vulnerability is classified as CWE-732 (Incorrect Permission Assignment for Critical Resource). The core issue stems from the Burn bootstrapper engine's use of the Windows GetTempPathW API when running with elevated SYSTEM privileges. When a WiX bundle installer runs as SYSTEM (which is common during software deployments via enterprise management tools or when elevated installation is required), the temp path resolves to C:\Windows\Temp rather than a user-specific temp directory.

The C:\Windows\Temp directory maintains permissive access controls that allow standard users to create files. This design creates a race condition opportunity where an attacker can anticipate which binaries the Burn engine will drop and load, then place malicious versions of those binaries in the temp directory before the legitimate bundle execution occurs.

Root Cause

The root cause is the inappropriate use of the system temp directory (C:\Windows\Temp) when executing with SYSTEM privileges combined with the subsequent loading of binaries from this world-writable location. The Burn engine drops and loads multiple binaries from this insecure directory without implementing proper integrity verification or using a securely-permissioned location. This violates the security principle of least privilege and fails to account for the shared nature of the system temp directory.

Attack Vector

The attack requires local access to the target system and involves the following steps:

1. Reconnaissance: The attacker identifies that a vulnerable WiX-based installer using the Burn engine will be executed with SYSTEM privileges (e.g., via scheduled deployment, user-initiated elevated install, or enterprise software distribution)

2. Binary Prediction: The attacker determines which binaries the Burn engine will drop to C:\Windows\Temp during execution

3. File Placement: Before the legitimate bundle runs, the attacker places malicious binaries with the same names in C:\Windows\Temp

4. Privilege Escalation: When the Burn engine executes as SYSTEM and loads the hijacked binary, the attacker's malicious code runs with SYSTEM privileges

The attack exploits the Time-of-Check Time-of-Use (TOCTOU) window between when files are dropped and when they are loaded, combined with the insecure directory permissions.

Detection Methods for CVE-2024-29187

Indicators of Compromise

• Unexpected executable files appearing in C:\Windows\Temp prior to scheduled software installations
• Suspicious process creation events where child processes of WiX bundle installers execute from C:\Windows\Temp
• File modification events in C:\Windows\Temp by low-privileged user accounts shortly before elevated installer execution
• Unusual DLL or executable files in C:\Windows\Temp matching naming patterns used by WiX Burn engine

Detection Strategies

• Monitor file creation events in C:\Windows\Temp by non-SYSTEM accounts, particularly for executable files (.exe, .dll)
• Implement behavioral detection rules for SYSTEM processes loading binaries from C:\Windows\Temp where the file owner is a standard user
• Use endpoint detection to alert on privilege escalation patterns involving temp directory binary execution
• Audit WiX-based installers in your environment to identify those using vulnerable Burn engine versions

Monitoring Recommendations

• Enable Windows Security event logging for file system auditing on C:\Windows\Temp
• Configure SentinelOne Singularity to monitor for suspicious binary loading patterns from world-writable directories
• Implement application allowlisting to prevent unauthorized executables from running in temp directories
• Deploy behavioral AI detection to identify anomalous privilege escalation chains

How to Mitigate CVE-2024-29187

Immediate Actions Required

• Upgrade WiX toolset to version 3.14.1 or later for the 3.x branch
• Upgrade WiX toolset to version 4.0.5 or later for the 4.x branch
• Rebuild existing installers using the patched WiX toolset versions
• Audit deployed applications for vulnerable WiX bundle installers and prioritize updates
• Implement application control policies to restrict execution from C:\Windows\Temp

Patch Information

The WiX development team has released security patches addressing this vulnerability. The fixes are available in versions 3.14.1 and 4.0.5. The patches modify the Burn engine to use a more secure temporary directory with appropriate access controls when running with elevated privileges. Security fixes can be reviewed in the following commits:

• WiX 4.x patch commit
• WiX 3.x patch commit

For detailed vulnerability information, refer to the GitHub Security Advisory GHSA-rf39-3f98-xr7r.

Workarounds

• Restrict write access to C:\Windows\Temp for standard users where operationally feasible (may impact other applications)
• Use application allowlisting solutions to prevent execution of unauthorized binaries from temp directories
• Implement Software Restriction Policies or AppLocker rules blocking executable execution from C:\Windows\Temp
• Monitor and clean C:\Windows\Temp before executing WiX-based installers in sensitive environments
• Consider running vulnerable installers in isolated environments until patches can be applied

# Example AppLocker rule to block executables from Windows Temp
# PowerShell command to create deny rule for %WINDIR%\Temp
New-AppLockerPolicy -RuleType Path -Path "%WINDIR%\Temp\*" -Action Deny -User Everyone