And if some malware figures out it can launch Quicken as elevated, so
what?
It still needs to find an exploit within Quicken,
You use quicken as an example of an administrative program, but this is a
terrible example - quicken is not (and should not be) a privileged program.
Any program should be able to launch quicken in its non-privileged state.
However, I can still use a theoretical "blessed-to-elevate" quicken to
exemplify what I am trying to state here.
You're assuming here that any program that is running with privilege does
not BY DESIGN, simply by the act of executing and in response to command
line switches, do something privileged.
You can't assume that!
In fact, if a program is requesting admin permission from the user, then the
opposite assumption should be made: that the privileged program is, in fact,
going to do an admin operation when it starts running that an unprivileged
program would not (and should not) be able to do.
There is no 'exploit' required: the very fact that privileged action(s)
(encapsulated by a privileged process) are being executed at the request of
an unprivileged process, without confirming that the user initiated the
action, is in a very direct way making whatever privileged actions that the
privileged process takes available to all unprivileged applications. And
this is the BEST CASE scenario. Any further 'tinkering' that the
unprivileged application can do to squeeze more privilege out of the
privielged application is just icing on the cake.
My point can be stated by example very clearly with common administrative
programs. Let's say you format disks all the time, so you bless the format
command. Unprivileged code can now format disks [an administrative action]
by launching the format command without you knowing about it, all without
modifying the format EXE or injecting code into its process - by simply
causing to happen the action that FORMAT was designed to do. And this is the
BEST CASE scenario.
Sure, the unprivileged program cannot thru API format the disk in its own
right - but it can use format.exe to accomplish this, in the same way
(semantically) as if it had the privilege to do so all along.
As an example of the worst case scenario, there could be a bug say in the
format code that processes command line switches, that ends up allowing an
attacker to run arbitrary code - whoops, the unprivileged process can now
perform ANY privileged action, not just format hard drives!
Current UAC design prevents both the worst case and the best case scenario -
as it should - since the best-case scenario is a slippery-slope to the worse
case, and allowing this to happen would be tantamount to architecting UAC to
fail.
And to move back to the quicken example - an unprivileged program could
cause even another unprivileged program that happens to run with privilege
to perform a privileged operation with disasterous side-effects. For
example, one could abuse any command-line exposable behavior or
automatally-performed-on-startup behavior of quicken that, when ran in a
privileged environment, would leak privilege.
Granted, in the "quicken" case (a program designed NOT to be privileged
which happens to be RUNNING with privilege) it would be harder for an
attacking program to take advantage of it [but not as hard as you suggest,
as attacking it would not require modifying its code, simply passing in
command line arguments], but again this is the LEAST LIKELY case - the MOST
LIKELY case is that the user will bless a program to run that IS DESIGNED to
perform some administrative action and is DIRECTLY abusable by unprivileged
applications.
To look at the problem in a more complete way:
- Administrative actions are abstract things that are implemented in code
that uses the privileges assigned to the user and exposed by the system.
- Administrative programs are programs that implement and expose one or more
administrative actions
- Administrative programs are allowed to use ALL THE PRIVIELGES assigned to
the user in order to carry out their functionality
- Non-administrative programs may only use specific privileges, not ALL of
the privielges that a user has
And, my point: Allowing unprivileged programs to launch privileged programs
allows those unprivileged programs to perform administrative actions (which
are composed of privileged actions).
Sure, unprivileged code cannot DIRECTLY access the underlying
admin-resitricted privileges without taking control over the administrative
program/process (which is what you are pretty much saying in your post) -
but they can perform the abstract administrative action composed of the
restricted privileges, which is just as bad.
UAC prevents this form of attack by ensuring that the user started
administrative programs, as opposed to some malicious program.
and if it does,
it may as well just wait for the user to launch Quicken and the malware
can do it's thing (including installing a service, thereby bypassing UAC
in the future)
Again, you are assuming here that an exploit would be required for an
unprivileged process to effectively abuse a privileged one. Based on this
assumption, you assume that malware that could perform such an exploit by
starting a privileged application could just as easily perform the same
exploit on a privileged process that it did not start.
These are both invalid assumptions. An exploit (changing the code) is not
required. The unprivileged process can perform malicious privileged actions
through the normal actions that the privileged programs ALREADY DO.
Not at all -- UAC isolates elevated and non-elevated applications, which
prevents a non-elevated application from injecting DLLs (or whatever
else) into elevated application space, or otherwise controlling that app
(again, in the general case -- Specific applications may be exploitable,
but if so, and if those apps need to be elevated to run, the malware can
simply wait for the app to get launched by the user)
What you say is technically correct; however, it does not refute my
statement.
Allowing an unprivileged process to launch a privileged process on its own
behalf in a very real sense gives that unprivileged program the power to do
everything that the privileged program does.
And this is the *BEST CASE* scenario!!! - the unprivileged process can only
perform the limited administrative actions that the privileged program
exposes to the user thru command-line switches (or that it does
automatically via startup).
The WORST CASE is, as you suggest and as I implied, the unprivileged program
is able to somehow take over the administrative program and directly perform
any privileged action.
You are telling me that the WORST CASE would be extremely rare and would be
an "acceptable risk". And I understand what you are saying, although I don't
agree with this... (this is what I would consider 'architecting for
disaster'. If you are talking about the design of a system, which would be
UAC which allows application blessing, where compliance with the design
would be IMPOSSIBLE [preventing unprivileged apps from performing privileged
actions], then what exactly is the point of implementing? In other words,
saying 'its OK because it only expresses this under X scenario' may be OK
when IMPLEMENTING something, but is complete UNACCEPTABLE when DESIGNING
something)
However, the point I am making is that the situation that would exist in the
ABSOLUTE BEST CASE isn't much better than the WORST CASE!
I don't much care what app on my system wants to launch Quicken (okay, I
wouldn't be caught dead using Quicken, but it's a good average end user
example)
It could be me initiating the action, or it could be malware, either
way, there is no harm done unless I choose to allow that app to always
run elevated.
OK, so there's no harm done until you allow an app to always run elevated. I
agree with that statement. However, once that's happened, the integrity of
UAC is no longer enforcable. You've just broken UAC in a fundamental way,
that will lead eventually to the complete technical failure of UAC.
Because essentially, what blessing an administrative program is doing, is
telling UAC "this action IS NO LONGER AN ADMINISTRATIVE ACTION - even though
the system still thinks it is and may *depend* on this action being
restricted, I want ANY UNPRIVILEGED APPLICATION to be able to perform this
task."
UAC has no way of ensuring that this won't lead to system compromise, and in
fact this is the only logical outcome.
While it's potentially not as secure (allowing CMD to run elevated, for
example), it's a fair sight better then having users simply turn off
UAC.
There is no "potentially" about it - allowing the behavior you suggest would
implicitly allow ALL non-privileged programs to perform whatever
administrative actions you bless (essentially making those administrative
actions "non-administrative") - and this is the BEST-CASE scenario. In the
worst case scenario, you completely GET RID of the privilege seperation UAC
enforces, effectively nullifying UAC.
Another thought (and one I could see being far more useful, at least in
my line of work) would be to have some way to launch startup programs
elevated. This is one case where I might want something to happen which
requires elevation, but I definitely do not want to be prompted on every
bootup.
You can already do this with the task scheduler.
As long as adding an app to the "run this elevated on bootup" required
elevation, and whatever process launched the elevated apps would ensure
that no un-elevated writes were possible to the startup EXE, it wouldn't
open any security holes in the general sense.
The computer starting up is an event that happens, not something that a
(non-elevated) process can start to happen. Thus, launching admin programs
on this event wouldn't leak privileges anywhere, assuming that the
requirement of not allowing unprivileged programs to muck about with either
the event or the program being launched is kept.
This is completely different than allowing a program to always be blessed:
the starting of a program in this case is directly controllable by
unprivileged programs, and thus leaks privilege, always.
(FWIW, I'm actually working on something that does just this using logon
scripts, and semaphore files for inter-process communication to allow
the un-elevated user and the elevated pseudo-service to communicate. Is
it a security hole? Yes. Is it exploitable? In the general sense, no,
it would require fairly intimate knowledge of the technique I'm using,
plus it will require an app to be elevated at least once to take
advantage of it -- If an app could get elevated once, it could just
install itself as a service and bypass this whole mess)
I'm not sure if I understand what you are saying here.
You say "would allow the unelevated user to communicate with the
pseudo-service" in one sentence and then "will require an app to be elevated
at least once to take advantage of it " in another - these statements are
mutually exclusive. If your program allows an unelevated program to cause an
elevated program to launch without user consent, then you have to assume
that *ANY* unelevated program can perform that operation.
The attacker doesn't have to figure out your system, it can be as
complex/obfuscated as you want it. They just have to figure out how to cause
your really-privileged-but-the-system-thinks-is-unprivileged process to do
what the attacker wants - and I think this would be more exploitable than
you think.
Another thought, and one that is potentially far easier to exploit,
create an app that injects itself into Explorer, and waits until it sees
Explorer do something that would normally require elevation (so the user
is expecting the prompt, and will authorize it), then jump in and
request elevation. I'd bet most users wouldn't even notice (and if the
app is well designed, it will take the appropriate action anyway, so the
user doesn't have a hope of noticing)
Fascinating thought
.
All in all, I have UAC enabled on my system and don't really plan on
changing that, although I did use a group policy to automatically
elevate (I'm more interested in the virtualstore/redirection of \Program
Files\ and similar, which finally lets the last few "I've gotta have
admin, I've really gotta have admin, even though I don't need it, I just
like to write in the \Program Files\ directory" software packages run
without opening up NTFS permissions more then I'm comfortable with.
So your system is essentially running in "all administrative actions are
blessed" mode. This means that all programs that say that they need
privilege will get privilege, and all privileged programs will be allowed to
run, even if you did not start them.
I agree this is marginally better than turning UAC off, in the same way that
I would agree that having a "blessing" system would be marginally better
than turning UAC off.
But you essentially HAVE turned the most important parts of UAC off.
You still get the "programs that SAY they don't need privilege don't have
them" benefit.
But you don't get the most important benefits of all:
- the knowledge that ALL privileged actions were initiated by you (any
program can now perform privileged actions without you knowing about it,
either by directly asking for such privilege and automatically receiving it
or by abusing some other program that has privilege)
- the right for *YOU* to decide whether a program requesting privilege
deserves to have it (any program, including malware, can SAY they need
privilege, even if they don't or you don't want them to, and you have no
chance to say "hey wait a minute no you don't").
--
In light of these technical issues with the current design of Windows/UAC, I
do believe it is possible to architect Windows/UAC such that the need for
the prompt can be minimized or eliminated, which would make this whole
stinky 'blessing' business a non-issue.
--
- JB
Microsoft MVP - Windows Shell/User
Windows Vista Support Faq
http://www.jimmah.com/vista/
