A security vulnerability report arrived that went something like this:
There is a vulnerability in the
XYZ.EXEprogram. If you place a hacked copy of the file
CABINET.DLLin the same directory as
XYZ.EXE, then when the user runs the
XYZ.EXEprogram, it loads the hacked
CABINET.DLLinstead of the real one. When
XYZ.EXEprompts for elevation, the user will allow it, and now the rogue
CABINET.DLLis running code as administrator.
First of all, this is an application directory attack, and the application directory is considered a trusted location. If you let somebody write to your application directory, then you are giving them control over what the application does. So don't do that.
This particular variation tries to disguise the matter by throwing in an elevation prompt, but the underlying issue is the same. Let's look at it another way: Who is the attacker, and who is the victim?
The attacker is the user who creates a trap in the application directory. The victim is the person who runs the application and gets caught in the trap. But how do you get the victim to wander into the yucky hot tub? Whatever technique you used to get them to run a program from your hot tub, you can use that technique to get them to run a rogue app directly; no need for fancy application directory attacks.
The other possibility of a victim is the user himself,
who runs the
and discovers that he just fell into his own trap.
It's not really considered elevation if you manage to fool