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)
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.
Comment 1•13 years ago
|
||
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).
Reporter | ||
Comment 2•13 years ago
|
||
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.
Comment 3•13 years ago
|
||
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.
Description
•