4 ms·
The installer tries to load a dll called version.dll. As the default behavior on windows is to load from the same folder as the started binary first, it finds t
by wila 11y ago
The installer tries to load a dll called version.dll. As the default behavior on windows is to load from the same folder as the started binary first, it finds the malicious dll and loads that.
- alkonaut 11y agoI don't get why an installer would ever load an external dll? The installer should bundle all of its own logic AND all the code of the application it's installing. That's kind of the point of making an installer in the first place. When is it useful to have a dll next to an installer (for non exploit purposes)?
- wila 11y agoThe installer depends on functionality available within windows. In this case, the version.dll is loaded indirectly by windows or the installer dependencies. The version.dll is a standard Microsoft DLL, just checked it here on a few systems and on Windows 7 it doesn't even appear to have been signed by Microsoft. Only starting in Windows 8 it has been signed. The version.dll provides very standard functionality such as Win32 API call GetFileVersionInfoA. It is the same thing as what you see in Windows explorer by right-clicking a binary such as exe or DLL and display the version info in the properties tab page. It is very commonly used functionality so lots of applications/installers will fall for this.
- alkonaut 11y agoI see. Then is seems the issue is that you can replace a normally signed OS-library with a local unsigned one like that. Having the OS libraries load before the local directory would resolve it just like GAC assemblies are preferred over locally resolved ones in .NET