Text 16094, 144 rader
Skriven 2007-02-14 17:56:26 av mike (1:379/45)
Ärende: Hacker, Microsoft duke it out over Vista design flaw
============================================================
From: mike <mike@barkto.com>


Not sure what to make of this one yet...

http://blogs.zdnet.com/security/?p=29

===
Joanna Rutkowska has always been a big supporter of the Windows Vista security
model. Until she stumbled upon a "very severe hole" in the design of UAC (User
Account Control) and found out — from Microsoft officials — that the default
no-admin setting isn't even a security mechanism anymore.

Rutkowska, a hacker with a track record of defeating Vista's security
mechanisms, believes UAC has a major flaw in the way it automatically assumes
that all setup programs (application installers) should be run with
administrator privileges.

"[When] you try to run such a program, you get a UAC prompt and you have only
two choices: either to agree to run this application as administrator or to
disallow running it at all. That means that if you downloaded some freeware
Tetris game, you will have to run its installer as administrator, giving it not
only full access to all your file system and registry, but also allowing it to
load kernel drivers! Why should a Tetris installer be allowed to load kernel
drivers?," Rutkowska asked in a post on her Invisible Things blog.

That's because Vista uses a compatibility database and several heuristics to
recognize installer executables and, every time the OS detects that an
executable is a setup program, "it will only allow running it as
administrator."

This, in Rutkowska's mind, is a "very severe hole in the design of UAC."

"After all, I would like to be offered a choice whether to fully trust given
installer executable (and run it as full administrator) or just allow it to add
a folder in C:Program Files and some keys under HKLMSoftware and do nothing
more. I could do that under XP, but apparently I can’t under Vista, which is a
bit disturbing," she added.

A few days after Rutkowska flagged the UAC shortcoming, Microsoft's Mark
Russinovich wrote a detailed technical explanation of the way the mechanism
works. One thing that stood out in Russinovich's explanation is an admission of
sorts that the default configuration of UAC puts the user at risk of a
sophisticated code execution attack.

Russinovich, a technical fellow at Redmond, writes:

As you experiment you’ll find that your actions are limited, but there are some
design boundaries that you should be aware of. First, with the exception of
processes and threads, the wall doesn’t block reads. That means that your
low-IL command prompt or Protected Mode IE can read objects that your account
(the standard-user version if you’re a member of the administrator’s group)
can.

This potentially includes a user’s documents and registry keys. Even the
ability of a process at low IL to manipulate objects of a higher IL isn’t
necessarily prevented. Since processes running at different integrities are
sharing the same desktop they share the same “sessionö. Each user logon results
in a new session in which the processes of the user execute. The session also
defines a local namespace through which the user’s processes can communicate
via shared objects like synchronization objects and shared memory.

That means that a process with a low IL could create a shared memory object
(called a section or memory-mapped file) that it knows a higher IL process will
open, and store data in the memory that causes the elevated process to execute
arbitrary code if the elevated process doesn’t properly validate the data.

That kind of escape, called a squatting attack, is sophisticated and requires
the user to execute processes in a specific order and requires knowledge of the
internal operation of an application that is susceptible to manipulation
through shared objects.

Russinovich pegged it as a tradeoff between application compatibility and ease
of use, explaining the weakness as a "design choice."

Because elevations and ILs don’t define a security boundary, potential avenues
of attack , regardless of ease or scope, are not security bugs. So if you
aren’t guaranteed that your elevated processes aren’t susceptible to compromise
by those running at a lower IL, why did Windows Vista go to the trouble of
introducing elevations and ILs? To get us to a world where everyone runs as
standard user by default and all software is written with that assumption.

That explanation isn't sitting well with Rutkowska. In an e-mail interview, the
Polish malware researcher said she was "pissed off" by what she perceived as
Russinovich's flippant attitude to the potential risk.

"It seems like Microsoft realized that implementing UAC would be hard, so they
decided not to call it a security mechanism anymore and that
'potential avenues of attack, regardless of ease or scope, are not
security bugs'," she said, quoting directly from Russinovich's essay.

"I don't think it's fair after all this Vista security campaign we observed in
2006, where Microsoft was boasting about this new security model in Vista. This
is not a proper way to solve security problems. Microsoft, instead of trying to
diminish the problem, should work on the solutions (even if they expected to
see a dozen of new attacks against UAC)," she added.

Rutkowska also took issue with this line from Russinovich's argument:

"[H]aving your elevated AAM processes run in the same account as your other
processes gives you the convenience of allowing your elevated processes access
to your account's code and data, but at the same time allows your non-elevated
processes to modify that same code and data to potentially cause an elevated
process to load arbitrary code…"

"This is not valid," Rutkowska declared. "If we followed this reasoning, then
we would not be able to talk about security in our email clients nor web
browsers, because they all also access data and code which are not trusted."

Her final thought: "I believe that the Vista security model is a good thing and
that users can benefit from it, but Microsoft must change their attitude and
start treating them as security mechanisms."


[UPDATE: February 13, 2007] Rutkowska wrote in to clarify a few things that
appear confusing in the article above:

There are two different things, which should be distinguished:

1. The fact that UAC *design* assumes that every setup executable should be run
elevated.

2. The fact that UAC *implementation* contains bugs, the one noted in the
original blog entry that allows a low integrity level process to send
WM_KEYDOWN messages to a command prompt window running at high integrity level.

I was “pissed offö not because of #1, I was “pissed offö because Microsoft
employee — Mark Russinovich — declared that all
*implementation* bugs in UAC are not to be considered as security bugs
(see fact #2).

True, I also don’t like the fact that UAC forces users to run every setup
program with elevated privileges (fact #1), but, I can understand such a design
decision (as being a compromise between usability and security) and this was
not the reason why I wrote my follow up titled “Vista Security Model - A Big
Jokeö.
===

See article for links and better formatting.

 /m

--- BBBS/NT v4.01 Flag-5
 * Origin: Barktopia BBS Site http://HarborWebs.com:8081 (1:379/45)