This started as a change to address #187 by constructing fully specified paths to system DLLs. KnownDLLs already mitigates this type of attack, but it's good to be explicit.
This does not address addons; those seem like less of a security issue since an attacker would need to modify Winfile.ini to refer to one, and if they can do that, they probably already have access. About the most sinister thing I can think of is code running in user context that believes the user will elevate Winfile, so modifying Winfile.ini allows for EOP; but doing that can be done without DLL planting.
Note, although it seems moot, that Undelete was building a system path then ignoring it (which is what made me ask #432 .) Looking at the history of this code, I think it started as a performance optimization - originally it would explicitly look in the System directory for the DLL, and if it's there, call LoadLibrary without specifying a path.
This started as a change to address #187 by constructing fully specified paths to system DLLs. KnownDLLs already mitigates this type of attack, but it's good to be explicit.
This does not address addons; those seem like less of a security issue since an attacker would need to modify Winfile.ini to refer to one, and if they can do that, they probably already have access. About the most sinister thing I can think of is code running in user context that believes the user will elevate Winfile, so modifying Winfile.ini allows for EOP; but doing that can be done without DLL planting.
Note, although it seems moot, that Undelete was building a system path then ignoring it (which is what made me ask #432 .) Looking at the history of this code, I think it started as a performance optimization - originally it would explicitly look in the System directory for the DLL, and if it's there, call LoadLibrary without specifying a path.