Last year I had discovered an insecure library loading (DLL hijacking) vulnerability in McAfee VirusScan Enterprise. The vulnerability was triggered when a Microsoft Office file with an embedded ActiveX control was opened loading the library “traceapp.dll” in its current working directory which can be on a remote WebDAV or SMB share. The vulnerability was reported in version 8.5.0i and fixed in later versions.
Even though the vulnerability has been fixed it still suffers from a DLL hijacking vulnerability on the local machine. In order for this vulnerability to be exploited you will need to have access to the machine to begin with so this cannot be exploited remotely. As such its not a security risk as if you have access to the machine you can pretty much do anything anyway.
Now in McAfee VirusScan Enterprise there is a cool feature called “Access Protection”. With this feature we can disable most autostart entry points which malware use to load up. Stopping malware from loading up is a key mitigating feature as a simple reboot would resolve most infections. Some of the features McAfee’s Access Protection protects us from are:
Prevent programs registering to Autorun Prevent programs registering as a service Prevent installation of Browser Helper Objects and Shell Extensions
When all of the features in Access Protection are enabled it would prevent the machine reasonably well from infection so chances of malware autostarting are low. But due to this DLL hijacking vulnerability there is now another way of loading malware bypassing all these preventive actions.
If the library traceapp.dll has been placed in “C:\Document and Settings\user\” folder (where user is the username) then this library will autostart at bootup when McAfee VirusScan’s executables are loaded. Processes that load traceapp.dll from this location are McTray.exe, shstat.exe and UdaterUI.exe. To mitigate from this vulnerability we need to create a new rule to prevent traceapp.dll from auto starting from our user profile location.
During tests unfortunately even with the rule in place with the preventive action “Files being executed” the library still loads up as it seems the rules are only effective later in the boot process. So best action would be to enable the preventive action “New files being created”. This way the traceapp.dll can never be created in our user profile location to begin with after an infection if some malware did try to exploit this vulnerability.
This insecure library loading vulnerability effects upto the latest version 8.8.
Can you say if this is also present in Windows 7? None of the processes you mention are loading traceapp.dll in my system.
Hi Adrian, at the time I didnt test it on Windows 7. I just gave it a test now with VirusScan 8.8 (an evaluation copy) and the vulnerability doesnt seem to exist so its only effects Windows XP for autostarting the library.