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

Development Best practises that can protect against this weakness/vulnerability :
Tools to detect said bug class :
Mitigate this particular attack vector through GPO policies:
More information :
    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.