4 ms·

Can someone explain all the steps here? I get that: 1) the browser will silently download a DLL to the Downloads folder 2) the installer does something that

Can someone explain all the steps here? I get that: 1) the browser will silently download a DLL to the Downloads folder 2) the installer does something that causes the DLL to run, compromising the machine. I get why people don't like (1), but why is (2) actually happening? Are the DLL hijackers exploiting name collisions, is an API being abused, or something else? And is there a robust way to prevent this even if browsers persist in silent downloads?

windowsworkstoo 11y ago
https://blogs.msdn.microsoft.com/oldnewthing/20101111-00/?p=12303/ https://blogs.msdn.microsoft.com/oldnewthing/20101111-00/?p=...
jffry 11y ago
The linked article [1] has an explanation: In simple terms if an application (e.g. Test.exe) loads a DLL (e,g. foo.dll) by just the name, Windows follows a specific search order depending upon whether “SafeDllSearchMode” is enabled or disabled to locate the legitimate DLL. So it looks like the installer is legitimately attempting to load some DLL but either hasn't fully qualified the name or hasn't enabled this flag [1]: http://blog.opensecurityresearch.com/2014/01/unsafe-dll-loading-vulnerabilities.html http://blog.opensecurityresearch.com/2014/01/unsafe-dll-load...
- wila 11y ago
  I was interested so read the article. Enabling the "SafeDllSearchMode" flag doesn't help as it is not the current directory from which the DLL is loaded, but the startup directory from which the installer is run (eg. the Downloads folder). The directory from which the application is loaded is still the first directory from which DLLs are loaded with "SafeDllSearchMode" on. Moving current directory down in the search order doesn't help. edit: The Microsoft Security Research center also had a paper on this [1] and there it lists that "SafeDllSearchMode" also employs a "known DLLs" technique when this flag has been set. Now the question is if Microsoft has added this DLL as a known DLL or not. I don't see it in my registry, but it might be defined elsewhere (or I might overlook it) [1] http://blogs.technet.com/b/srd/archive/2014/05/13/load-library-safely.aspx http://blogs.technet.com/b/srd/archive/2014/05/13/load-libra...
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 ago
  I 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 ago
    The 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 ago
      I 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

windowsworkstoo 11y ago

https://blogs.msdn.microsoft.com/oldnewthing/20101111-00/?p=12303/ https://blogs.msdn.microsoft.com/oldnewthing/20101111-00/?p=...

jffry 11y ago

The linked article [1] has an explanation: In simple terms if an application (e.g. Test.exe) loads a DLL (e,g. foo.dll) by just the name, Windows follows a specific search order depending upon whether “SafeDllSearchMode” is enabled or disabled to locate the legitimate DLL. So it looks like the installer is legitimately attempting to load some DLL but either hasn't fully qualified the name or hasn't enabled this flag [1]: http://blog.opensecurityresearch.com/2014/01/unsafe-dll-loading-vulnerabilities.html http://blog.opensecurityresearch.com/2014/01/unsafe-dll-load...

wila 11y ago
I was interested so read the article. Enabling the "SafeDllSearchMode" flag doesn't help as it is not the current directory from which the DLL is loaded, but the startup directory from which the installer is run (eg. the Downloads folder). The directory from which the application is loaded is still the first directory from which DLLs are loaded with "SafeDllSearchMode" on. Moving current directory down in the search order doesn't help. edit: The Microsoft Security Research center also had a paper on this [1] and there it lists that "SafeDllSearchMode" also employs a "known DLLs" technique when this flag has been set. Now the question is if Microsoft has added this DLL as a known DLL or not. I don't see it in my registry, but it might be defined elsewhere (or I might overlook it) [1] http://blogs.technet.com/b/srd/archive/2014/05/13/load-library-safely.aspx http://blogs.technet.com/b/srd/archive/2014/05/13/load-libra...

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 ago
I 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 ago
  The 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 ago
    I 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