Investigation and Resolution of .exe.local Directory Vulnerabilities

Identifying Key Security Concerns

We have identified several critical security issues, including:

• The "comctl32.dll loading vulnerability" refers to a security issue where a malicious actor could potentially exploit the way Windows loads certain dynamic link libraries (DLLs) to execute unauthorized code and gain control over a system with elevated privileges, specifically the "System" account.
• A "GdiPlus.dll loading vulnerability during LanguageDlg action" involves a security issue with the loading of the 'GdiPlus.dll' dynamic link library (DLL) during the execution of the "LanguageDlg" action in a software or application. This vulnerability is categorized as a "dll hijacking" exploit and has the potential to grant an attacker elevated privileges, typically the "System" account, allowing them to run malicious code.
• A "Settings.ais vulnerability during Repair on advinst.msi" implies a security issue that arises during the repair process of an Advanced Installer project (advinst.msi) related to a file or component named "Settings.ais." This vulnerability is described as an exploit that, if successfully manipulated, could lead to gaining System account privileges.

Among our security issues, we only make a few public, like the DLL hijacking vulnerability.

Understanding Impact and Countermeasures

The vulnerability in question affects all modern Windows installations, revealing a discrepancy in the WinSxS subsystem's functioning as opposed to Microsoft's documentation.

Threat Level: High

Required Countermeasures: Temporarily disable the .exe.local mechanism until preloading of DLLs at installation start.

Concepts at Play: DLL Dynamics

We focus on two key areas:

• DLL search order and hijacking
• DLL redirection

Regarding the DLL search order and hijacking, Advanced Installer 12.7 and later employ Microsoft-recommended measures that prevent hijacking, as documented in

Secure loading of libraries to prevent DLL preloading attacks(1). Additional information regarding the search order can be found in Dynamic-link library search order.

That being said, the current issue is not related to the DLL search order, but to the DLL/COM redirection mechanism, which is a separate thing entirely. Its purpose was to establish a mechanism for the developer to provide a specific version of DLL dependencies, to isolate from issues introduced by a different DLL version in the future.

This mechanism was introduced in Windows XP but is now regarded as being deprecated and no longer in use in applications that have a manifest; we will give further details below. Documentation on this can be found at:

• Dynamic-link library redirection (2)
• DLL/COM Redirection on Windows (3)

Investigation Summary

Setup EXEs generated by Advanced Installer have an embedded manifest, and thus, the DLL redirection mechanism should be inactive while running the EXE.

According to documentation, the reported vulnerability cannot be reproduced, unless the system admin has explicitly forced global DLL redirection on that machine by setting the DevOverrideEnable DWORD value in the HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Option registry key to value 1. (See (2) for details).

In practice, however, we observe that the vulnerability occurs when the DLL is placed under a particular .exe.local subfolder structure (resembling the DLL parent folder from WinSxS), and regardless of the value of DevOverrideEnable. This forces us to take countermeasures, to ensure that adversaries do not exploit this vulnerability.

Methodology of the Investigation

As described in reference (1), Process Monitor offers a rigorous method for detecting the DLL paths Windows tries to load when running an application.

We employed specific monitor filters to observe the loading behavior of the sample.exe DLL during the installation process. This observation was conducted under several scenarios:

• EXE as built by Advanced Installer, with default Windows 11 DLL redirection settings (DevOverrideEnable not set).
• EXE as built by Advanced Installer, but with modified Windows 11 DLL redirection settings (DevOverrideEnable set to 1).
• EXE modified to remove the embedded manifest, maintaining default Windows 11 DLL redirection settings (DevOverrideEnable not set).
• EXE modified to remove the embedded manifest and with modified Windows 11 DLL redirection settings (DevOverrideEnable set to 1).
• EXE as built by Advanced Installer, using standard Windows 11 DLL redirection settings (DevOverride not set), with the DLL placed in .exe.local/PATH_FROM_WINSXS/gdiplus.dll.

All tests were conducted with the sample.exe.local directory present at the test site. Our focus was primarily on GdiPlus.DLL, as this was the specific case reported.

Scenario 1 is particularly crucial as it reflects the majority of systems that have not been altered. This scenario led to the following observations:

In this scenario, no other GdiPlus DLL paths were accessed or captured. The loaded path, as shown in the image, resides in C:\Windows\WinSxS, which is outside the risk zone for hijacking.

Scenarios 2 to 4 present a potential vulnerability. In these cases, Windows attempts to load the GdiPlus DLL from the sample.exe.local directory.

This situation creates a risk of hijacking the GdiPlus DLL. An attacker could exploit this by placing a malicious DLL in the .exe.local directory.

Scenario 5 led to the execution and elevation of privileges for the malicious DLL in all tests, on both Windows 10 and the latest version of Windows 11, highlighting a significant vulnerability. This occurred irrespective of the presence of a manifest, thus contradicting the existing documentation. Such behavior suggests a bug in the WinSxS subsystem.

Results and Observations

The observed results from our monitoring of the test data align only partially with Microsoft's documentation on the DLL Redirection mechanism.

In theory, the .exe.local DLL redirection mechanism should be disabled when a manifest is present. However, placing the DLL in the .exe.local/WINSXS_PATH/gdiplus.dll path results in the DLL being loaded regardless of the manifest's presence. This behavior contrasts with simply placing the gdiplus.dll directly in the .exe.local directory, where the Microsoft documentation's guidelines seem to apply.

Unfortunately, we haven't found a method to disable this redirection and its associated vulnerability. Therefore, as a countermeasure, our installers will search for any .exe.local file or directory before preloading DLLs and temporarily disable it (by renaming or relocating) until the DLLs are preloaded.

We anticipate that this approach will offer substantial protection against dotLocal DLL attacks.

Conclusion

In summary, this article highlights the steps taken to address and resolve the DLL hijacking vulnerability, demonstrating the importance of ongoing vigilance in software security.

Our findings and actions not only provide a solution to this specific issue but also contribute to a deeper understanding of such vulnerabilities.

This case serves as a reminder of the need for continuous adaptation and enhancement in security practices across the industry.

Stay informed about our latest security updates by subscribing to our newsletter.