What is to prevent a lower admin level program from hooking into the
Ack, that should have been, what is to prevent a malicious program from
hooking into a program that asks for admin privileges?
UAC does a few things to help prevent this:
- NTFS Permissions and the design of the prompt
Programs that elevate should really be located in
read-only-to-standard-user locations. The built-in Windows programs and
programs that are put in program files are, but of course the user is
free to put programs that elevate wherever the want.
Unfortunately, this problem is compounded by shortcuts. Shortcuts may
point to a secure admin program but live in an unprotected area.
In the worst case where a program being elevated is NOT in a read-only
location, then UAC temporarily copies the program to a secure location
before the prompt is displayed.
This prevents the 'ol switcheroo, so the program described by the UAC
prompt can be trusted to be the actual program that will be started if
accepted.
So, that means the attack vector is where malicious programs seek out
(or create) admin programs and sortcuts that point to admin programs
that live in an unsecured location and then modify or overwrite those
programs/shortcuts.
This problem is mitigated by the information shown in the prompt (name,
publisher, icon) and by showing a different style of prompt with
different button locations for higher-risk unsigned programs.
The only cases where the attacker would actually be able to display a
prompt that was EXACTLY the same as the expected prompt would be 1) if
the attacked program was not digitally signed, or 2) where the attacker
has specifically planned out and targeted a certain program and has
somehow acquired a digital certificate in the same name of the author of
the target program (not likely, but possible, and even though possible,
limited in effectiveness due to it being targeted so precisely at a
single program).
In all other cases where a signed program is being attacked, the
malicious prompt will look different, and in most cases, it will look
significantly different (either an unsigned program prompt will be
displayed, or a signed program prompt will be displayed where both the
icon and publisher will be different than expected).
This is because in the case of attacking a signed program, attackers
would not be able to actually modify the real program and inject their
code into it using virus techniques because this would invalidate the
digital signature - they would need to cause their own program to be
launched.
In order to display a prompt that looks more like the attacked program,
the attacker must both spend more resources (on digital signatures) and
narrow the scope of the attack to specific programs (making the attack
less effective).
For example, an unsigned prompt is MUCH different than a signed prompt.
If the attacker can get a digital certificate, then the difference will
only be in the publisher name and icon.
However, in the case where the attacker uses a digital signature, they
would not be able to dynamically change the information that will be
displayed in their prompt to match the attacked program (publisher and
icon) because doing so would invalidate their own digital signature.
The best chance of success would be if the attacker had pre-targeted a
specific program and could gain a digital signature that was confusingly
similar to the publisher of the program being attacked and have the same
icon.
In any case, this is still a valid attack vector, but much has been done
to mitigate this, much more than any other OS has done that has a
similar elevate-on-demand model.
- UAC prompts on secure desktop
Prevents programs from hooking into the actual prompt.
- UIPI User Interface Process Isolation and Mandatory Integrity Control
Prevents lower-privileged processes from gaining write or modify access
to higher privileged processes, or executing attacker-controlled code in
the context of the higher-privileged process.
