Holy cow, I wrote a book!
A bunch of security vulnerability reports came in from the same person,
all of the form,
"Program X is vulnerable to DLL planting if you create a DLL with
the name Y in a directory on the PATH,"
with varying values of X and Y.
In all the cases, Program X runs as SYSTEM
with the System32 directory as its
current directory, so a
current directory attack
does not apply here.
The only remaining directory to attack is the PATH.
But if you can attack the PATH for the SYSTEM user,
then you are already on the other side of the airtight hatchway.
The default PATH directories are all directories which are read-only
to non-administrative users.
In order to plant a DLL there, you must already be an administrator,
at which point you are on the other side of the airtight hatchway.
If you gain administrative access, then why bother planting DLLs
in sneaky places?
You already pwn the machine.
Just do whatever you want!
In other words, planting a DLL into secured directories can be
carried out only by administrators,
at which point it's just the administrator attacking his own computer.
The next angle of investigation is whether somebody can sneak an
insecure directory onto the global PATH.
But modifying the global PATH requires administrative privileges,
so if you have the privilege to add an insecure directory to the path,
you are already an administrator,
so this is another case of an administrator attacking his own computer.
Still not interesting.
Finally, the third option is that some application,
as part of its installation,
added an insecure directory to the global PATH.
But in that case, you don't need to do any DLL planting at all.
Just put a rogue executable on the PATH.
For example, you might call it
so that somebody who typos the type command
runs your rogue executable instead.
In other words,
in order for DLL planting into an insecure directory on the global PATH
you must already have a system whose integrity has already been violated,
albeit inadvertently in this case.
If you have an attack along these lines, then
the security vulnerability is in the application
whose installer added an insecure directory to the global PATH.
This is another case of
If you set up an insecure system,
don't be surprised that there's a security vulnerability.
Now, there is still a flaw in the application
that gets tricked into loading the rogue DLL.
It should be more specific about how it loads
DLLs so it doesn't load the wrong one by accident.
But there is no elevation of privilege,
since only administrators can trick the application into loading
the wrong DLL.