Subscribe to the RSS feed in case you are interested in updates
After Acrossecurity, published an interesting vulnerability and HDmoore appears to have stumbled on the same issue, I decided to investigate on my own. I am not 100% sure it's the same bug but I am pretty confident. While it is known since years and Microsoft even dedicates a KB article to it, vendors appear to still have issues with using Loadlibrary/Getprocadress correctly.
Above does not show vulnerable examples (i.e the dll is not effectively loaded)
This issue appears to have been first discovered by Georgi Guninski (who else) in 2000, so it is not a new weakness and defensive mechanisms have been introduced into development languages as well as windows itself to mitigate this risk (if properly used)
If I will find more time this week I'll publish more details and backround as to introduce counter measures and checks into your hopefully mature Development Lifecycle.
In summary :
If loadlibrary is not called correctly AND/OR DLL Search path is not hardened opening a file located on a share will lead to DLL files being located on the share and code being executed that is within that DLL. Above is an example of Photoshop.
Until then know that this issue can be mitigated by deploying proper GPO policies that disables searching for DLLs on UNC paths (Documented in http://support.microsoft.com/kb/2264107)
Development Best practises that can protect against this weakness/vulnerability :
- Do not use the SearchPath function to retrieve a path to a DLL for a subsequent LoadLibrary call. Why : http://msdn.microsoft.com/en-us/library/ms684175(VS.85).aspx
- More to follow in the following days
Tools to detect said bug class :
- DLL Hijacking Audit Tool v2 by Rapid7/HDmoore and Blog post (Recommended read)
- Rapid7 Blog post (Interesting backround information)
- Procmon (Sysinsternals)
- Filemon (Sysinsternals)
- http://support.microsoft.com/kb/2264107
- More information from the SRD Team (recommended read)
- Paper by Taeho Kwon and Taeho Kwon entitled Automatic Detection of Vulnerable Dynamic Component Loadings
- DLL preloading Microsoft Security Response Center blog
- Official security Advisory
Expect a lot of applications vulnerable to this bug and my title CVE-2010-x+n probably makes sense by now. Another low hanging fruit to watch out for.