Closed Bug 671086 Opened 13 years ago Closed 13 years ago

use SetDefaultDllDirectories on Windows to avoid local DLL load hijacking

Categories

(Core :: Security, defect)

x86
Windows Vista
defect
Not set
minor

Tracking

()

RESOLVED WONTFIX

People

(Reporter: imelven, Unassigned)

Details

http://msdn.microsoft.com/en-us/library/hh310515%28VS.85%29.aspx
describes a new API SetDefaultDirectories made available in Windows Vista and Windows 7 in an automatic update shipped 7/12/2011

this API allows an application to specify a set of default directories to search when a LoadLibrary call does not specify an absolute path

this is intended to mitigate against the local attack (with privileges to write to whatever dirs are in the default windows DLL search path) where a malicious DLL is dropped in a directory that comes earlier in the DLL search path than the actual location of the real DLL

an alternate approach here would be to audit all LoadLibrary() calls but this API solves the problem nicely and protects future LoadLibrary() calls as well

note that the API is not a base shipping Windows OS yet and needs to be dynamically loaded so we can work on systems that don't have this patch installed.
We tried the precursor to that, SetDllDirectory(), in bug 286382. Despite that being the MS recommendation at the time, using it broke Silverlight (bug 286382 comment 75).
wow, quite a lot of history in bug 286382, the takeaway seems to be that making a change along these lines, can (and has) broken several plugins

another note is that LoadLibrary usage has been audited at least a couple of times and specific issues have been fixed. it would be nice to have this in for new callers of LoadLibrary and as a belt-and-suspenders approach, but the risk of breakage seems pretty real and pretty high.
I don't think that using SetDefaultDllDirectories actually gives us any additional advantages on top of SetDllDirectory which we already use.  And this API is not available on Windows XP, which means that we would be even more inconsistent with the usage of this API on Windows, which is a bad thing.  We may be able to reconsider this when we decide that we're no longer going to support Windows XP...
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.