On Thu, Aug 26, 2010 at 1:18 AM, Carl Houseman <c.house...@gmail.com> wrote: > And those are likely just the beginning. I'd expect the number to get to > 100's of apps.
I expect it to be in the thousands, if not tens or hundreds of thousands. Keep in mind that most executables probably won't be tested for this, so we'll never see a vulnerability notice for them. Waiting for a list of programs which are or are not vulnerable is not a good way to approach this problem. The assumption should be that any given executable is vulnerable. Don't even bother trying to identify executables which call SetDllDirectory; there's still the question of whether it is called correctly or consistently. The default behavior of the system is broken. We cannot expect any programmers to actually implement the obscure feature which changes the default behavior. Expecting vendors to do so is not realistic. A huge number of Microsoft's own executables do not implement the setting and attempt to load optional DLLs. If Microsoft can't get their own code to do it, expecting others to do so is unrealistic. Assume everything is vulnerable. My suggestion would be: Deploy the update in MSKB 2264107. Configure CWDIllegalInDllSearch to remove the current directory from the search path by default system-wide. Identify any programs which stop working and make executable-specific exceptions to CWDIllegalInDllSearch for them. Contact vendors of those applications for updates (good luck with that!). Ideally, use Software Restriction Policies/AppLocker to limit loading of DLLs from trusted locations only. -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
