Breaking Changes to MSI Repair Functionality
Recently, Microsoft introduced a significant change that fundamentally breaks the MSI repair functionality. This change was made in response to a security vulnerability, CVE-2024-38014, and the details of the exploit can be found here. However, the impact of this change is severe and could lead to widespread issues within a client’s application portfolio. Let’s explore the old and new behaviors of the Windows Installer Service, the implications, and possible mediation steps.
Old Behavior (1999 to September 2024)
For many years, clicking on a shortcut deployed by an MSI would trigger the Windows Installer Service to verify that the application was correctly installed. If the service detected that the application was somehow broken, it would automatically initiate a repair process.
This process wasn’t limited to just the main application files. It also checked the registry, including user profile files and settings. This allowed IT teams to deploy packages via MCM (Microsoft Configuration Manager) running under the system account. When the user launched the shortcut for the first time, the Installer Service would detect any missing user files or settings and retrieve them from its cache. This would ensure the application launched correctly, without requiring local admin privileges for the user or the installer during the repair.
Since the Installer Service operated with SYSTEM-level privileges, it could fix issues in machine-wide folders (such as C:\ProgramFiles), where files were often mistakenly removed by uninstallers.
New Behavior (After September 10, 2024 – KB5043055)
Following the recent KB5043055 update, the Windows Installer Service now prompts for elevation (admin credentials) whenever it performs a repair, regardless of the specific scenario. This means that if a user launches a shortcut and is missing the required settings in their profile, they will be asked to provide admin credentials to proceed.
This shift is a dramatic departure from previous behavior and imposes new challenges, especially for environments with non-admin users, like most application portfolios.
The Impact
The change has disrupted a previously popular method for applying per-user settings within MSI files. As of now, it’s unclear exactly how many users, computers, or applications are affected, though these metrics could potentially be scripted for further analysis.
In addition, the update introduces various related issues:
- BitLocker: Users may face issues decrypting a BitLocker data drive when moving it from a newer version of Windows to an older version.
- Unified Write Filter (UWF): Windows Management Instrumentation (WMI) API calls for shutdown or restart might throw “access denied” exceptions.
- Azure Virtual Desktop: A deadlock could prevent users from signing into their sessions.
Mediation: How to Revert to the Old Behavior
If you need to restore the old behavior and avoid the UAC prompts during MSI repair, you can modify the following registry key:
HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer
DisableLUAInRepair (DWORD) = 1
It’s important to note that a reboot is required after changing this key for the setting to take effect. While there’s likely a Group Policy Object (GPO) setting that mirrors this change, this registry edit can serve as a temporary fix.
Risks of Reverting the Change
While this registry tweak helps bypass the UAC prompt, it’s worth considering the risks associated with reverting Microsoft’s security fix. In my opinion, the attack vector for CVE-2024-38014 is obscure and not particularly relevant to most users.
The recent update appears to go far beyond the necessary steps to mitigate the issue, and it’s concerning that Microsoft implemented such a fundamental change without adequately documenting or warning about its side effects—especially for organizations with non-admin users.
By enforcing admin credentials for repairs that involve user profile settings, this change blocks user settings from being written in scenarios that don’t actually require elevated permissions.
Test Package for Validation
In our research, we tested a simple MSI package. This package includes one registry entry in the user profile and one file in ProgramFiles(x86). When the shortcut is run, the MSI adds the user-based registry entry before launching the program. The results confirm the impact of the update.
Additional Notes
It’s worth mentioning that this issue does not seem to affect packages installed through MECM (SCCM) or anything installed by the system user.
Conclusion:
The changes introduced by Microsoft’s KB5043055 update have caused significant disruptions, especially in environments with non-admin users. While a registry edit can temporarily mitigate the issue, careful consideration of the associated security risks is essential. As more information emerges, most organizations should evaluate the impact on their application portfolio and plan accordingly.
