[cap-talk] Windows Vista: security by admonition

Micah Brodsky micahbro at csail.mit.edu
Mon Jun 5 03:37:42 EDT 2006


Hey, all. I'm one of the MIT grad students working on Asbestos. I've been
lurking for a bit, but I think I'll wade in (with a crosspost ;).

---

Actually, I think blaming the lack of an unforgeable input path to Explorer
is missing the point. 

More fundamental than needing trusted input is having a privileged,
protected shell. (If the shell has the ability to grant privilege, then it
itself must be privileged.) Authenticated user commands do no good if
malware can just attach a debugger or call WriteProcessMemory and mess with
the shell's execution state to trick it into invoking privileges. A
privileged shell not necessarily good idea, however. Shells are big,
complicated, extensible, and highly environment-dependent. Explorer is a
particularly bad example, supporting zillions of legacy in-process
extensions (e.g. right click to WinZip, browse pocket PC contents, etc.),
capable of embedding the entire web browser, and, I suspect, frequently
abused by applications via IPC. Even with a cleaner, more self-contained
shell, the vulnerability exposure due to state shared under this mechanism
would be staggering -- consider how much of a nightmare writing secure
SetUID programs on Unix has proven to be. 

As much as I agree that "security by designation" leads to better practical
security than "security by admonition", I think it has to be balanced
against the technical security risks it introduces. In this particular case,
the problems seem to me to be too daunting.

Personally, I'm beginning to wonder if more of a role-based scheme might be
better here than both approaches. Rather than providing an elevation
mechanism, maybe the system should just advise the user that they need to
switch to "administrative mode" to perform a given task. Since users cannot
effectively make use of the system's regurgitated explanation of its
interpretation of their actions (popups), perhaps it just makes more sense
to give users the option to designate explicitly when they intend to
exercise special privileges. I sort of imagine popping up a miniature
desktop with a special color scheme and a trusted input path, with the old
desktop greyed out in the background. Maybe the system would be smart enough
to bring up the same control panel window or folder the user was previously
trying to manipulate or launch an application from. In a sense, this would
be holding the user's hand through logging in as root.

All that being said, I'm not really sure what UAC is trying to accomplish in
terms of security for ordinary desktop users. Running with only user
privileges, malware can still root applications, destroy data, spy on user
behavior and keylog, render the system flakey and unusable, send spam, and
propagate over the network via application-level vulnerabilities and social
engineering. It's just easier to clean up afterward by trashing all your
personal settings instead of trashing the installed software along with your
personal settings. (Maybe families with untrustworthy kids will care, or
something.) This just seems to be the general inadequacy of user-granularity
access control.

--Micah



More information about the cap-talk mailing list