Both Sides on the Win7 UAC Problem (
Page 1 of 2 )
A controversy erupted last week with the revelation by a researcher that it is possible for a user-mode program in Windows 7 to disable User Access Control in the default configuration.
My first reaction to this was that it was bad, but it's a beta and it
will be fixed. Now I'm getting the vibe from Microsoft that it won't be
fixed and I can see their argument. It still leaves me uncomfortable,
though.
For those of you unfamiliar with the specific problem, in Windows 7
the default behavior of UAC was changed so that the user is not
prompted for access to Windows programs, such as control panel applets,
as they are in Vista. UAC also no longer uses the "secure desktop" mode
for confirmation by default.
And a new control panel is provided to let the user choose the
behavior of UAC in Windows 7. There is a slider control with 4 levels:
level 4 is the same as Vista, with all the same prompting for
system-level changes and secure desktop; level 3, the default, is the
same as level 4, but doesn't prompt for changes in Windows settings,
like the control panel; level 2 is the same as level 3, but does not
use the secure desktop; and level 1 shuts off UAC; no prompting at all.
The secure desktop is a special mode in which you can only interact
with the UAC prompt, and no other software.
The proof of concept showed a user-mode program which spoofed
keystrokes and mouse movements to change the setting from the default
down to level 1.
What bothered me was that this was user-mode code. It seemed to me
that it sort-of violated at least the spirit of UAC by indirectly
elevating privilege through an external program, which level 3 is
supposed to prompt. The author of the attack proposed what seemed a
sensible solution: force a prompt, one that requires secure desktop,
for that one case. The heart of the argument for making this a special
case is that users would expect from level 3 that it would protect them
from elevation changes from external programs.
There was a lot of hyperbole about this issue. There are many
legitimate arguments that this isn't so bad a problem, and in fact not
surprising at all. Some of them are made in Roger's Security Blog,
who closes with the point that a lot of the criticism is hypocritical,
amounting to calls for more rigid prompting from people who complained
about it in Vista..
The more I've thought about it, the more I think Microsoft is right
not to make a change here. Here are the major arguments for this
position.
You have to run an untrustworthy external program for the attack to
work. The fact that the attack can be a VBScript is of no importance.
It's generally understood that once you run some arbitrary program on
your computer you are putting yourself at risk. So the attack gets a
foot in the door through the user's fault, not Windows'.