use SetDefaultDllDirectories on Windows to avoid local DLL load hijacking

RESOLVED WONTFIX

Status

()

--
minor
RESOLVED WONTFIX
7 years ago
7 years ago

People

(Reporter: imelven, Unassigned)

Tracking

Trunk
x86
Windows Vista
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
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).
(Reporter)

Comment 2

7 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

7 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
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.