A DLL search order hijacking vulnerability in Thermalright TR-VISION HOME on Windows (64-bit) allows a local attacker to escalate privileges via DLL side-loading. The application loads certain dynamic-link library (DLL) dependencies using the default Windows search order, which includes directories that may be writable by non-privileged users.\n\n\n\nBecause these directories can be modified by unprivileged users, an attacker can place a malicious DLL with the same name as a legitimate dependency in a directory that is searched before trusted system locations. When the application is executed, which is always with administrative privileges, the malicious DLL is loaded instead of the legitimate library.\n\n\n\nThe application does not enforce restrictions on DLL loading locations and does not verify the integrity or digital signature of loaded libraries. As a result, attacker-controlled code may be executed within the security context of the application, allowing arbitrary code execution with elevated privileges.\n\n\n\nSuccessful exploitation requires that an attacker place a crafted malicious DLL in a user-writable directory that is included in the application's DLL search path and then cause the affected application to be executed. Once loaded, the malicious DLL runs with the same privileges as the application.\n\n\n\nThis issue affects \nTR-VISION HOME versions up to and including 2.0.5.
The vulnerability is exposed when the affected application is executed on a Windows system where it resolves DLL dependencies using the default search order that includes directories within the user profile or other user-writable locations. Because these directories are writable by non-privileged users, an attacker running with standard user permissions can place a malicious DLL with the expected filename in the search path. When the application is subsequently executed with elevated privileges, the malicious DLL will be loaded and executed within the elevated security context.
Until a vendor patch is available, administrators may mitigate the vulnerability by placing the legitimate DLL dependency in the application's installation directory, ensuring it is loaded before any user-controlled locations in the DLL search order. This reduces the likelihood that a malicious DLL placed in a user-writable directory will be loaded.\n\n\n\nAdditionally, administrators should ensure the application's installation directory is not writable by non-privileged users. Application control mechanisms such as Windows Defender Application Control (WDAC) or AppLocker may also be used to restrict the loading or execution of untrusted DLL files.
The issue can be resolved by modifying the application to load DLL dependencies using absolute paths or by restricting DLL loading to trusted directories such as system library locations. Additionally, implementing digital signature verification for loaded libraries can prevent malicious DLLs from being executed.
The issue can be resolved by modifying the application to load DLL dependencies using absolute paths or by restricting DLL loading to trusted directories such as system library locations. Additionally, implementing digital signature verification for loaded libraries can prevent malicious DLLs from being executed.