The implicit assumption here is that you need administrative privileges to be able to do bad things... when you make it explicit, however, it should become obvious that this is false...

said by »theinvisiblethings.blogspot.com/···day.html :

...
One thing that I found particularly annoying though, is that Vista automatically assumes that all setup programs (application installers) should be run with administrator privileges. So, 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 e.g. to load kernel drivers! Why Tetris installer should be allowed to load kernel drivers?
...

said by »blogs.technet.com/markrussinovic···372.aspx :

...
In Vista’s integrity model, every process runs at an integrity level (IL) and every securable object has an integrity level. The primary integrity levels are low, medium (the default), high (for elevated processes) and system. The windowing system honors integrity levels to prevent lower-IL processes from sending all but a few informational window messages to the windows owned by processes of a higher IL, calling this protection User Interface Privilege Isolation (UIPI). The security model also changes in Vista to only allow a process to open an object for write access if the process IL is equal to or higher than that of the object. Further, to prevent access to secrets stored in memory, processes can’t open processes of a higher IL for read access.
...
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, 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.

However, let’s be clear that no matter how difficult to pull off, the mere possibility of such a breach of a sandbox wall implies that ILs, in and of themselves, do not define security boundaries. What’s a security boundary? It’s a wall through which code and data can’t pass without the authorization of a security policy. User accounts running in separate sessions are separated by a Windows security boundary, for example. One user should not be able to read or modify the data of another user, nor be able to cause other users to execute code, without the permission of the other user. If for some reason it was possible to bypass security policy, it would mean that there was a security bug in Windows (or third-party code that allows it).

It should be clear then, that neither UAC elevations nor Protected Mode IE define new Windows security boundaries. Microsoft has been communicating this but I want to make sure that the point is clearly heard. Further, as Jim Allchin pointed out in his blog post Security Features vs Convenience, Vista makes tradeoffs between security and convenience, and both UAC and Protected Mode IE have design choices that required paths to be opened in the IL wall for application compatibility and ease of use.
...
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.

said by »theinvisiblethings.blogspot.com/···oke.html :

Oh, excuse me, is this supposed be a joke? We all remember all those Microsoft’s statements about how serious Microsoft is about security in Vista and how all those new cool security features like UAC or Protected Mode IE will improve the world’s security. And now we hear what? That this flagship security technology (UAC) is in fact… not a security technology!

I understand that implementing UAC, UIPI and Integrity Levels mechanisms on top of the existing Windows OS infrastructure is a hard task and it would be much easier to design the whole new OS from scratch and that Microsoft can’t do this for various of reasons. I understand that all, but that doesn’t mean that once more people at Microsoft realized that too, they should turn everything into a big joke? Or maybe I’m too much of an idealist…

said by »theinvisiblethings.blogspot.com/···oke.html :

There are two things which should be distinguished:

1) The fact that UAC design assumes that every setup executable should be run elevated (and that a user doesn't really have a choice to run it from a non-elevated account),

2) The fact that UAC implementation contains bug(s), like e.g. the bug I pointed out in my article, which 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, but because Microsoft employee - Mark Russinovich - declared that all implementation bugs in UAC are not to be considered as security bugs.

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 "The Joke Post".

said by Evan, on Joanna's blog :

Mark's posting is frustrating because Mark is speaking to technical fact in a manner that is obtuse, and isn't in sync with the marketing-type statements that Microsoft makes.

Mark says that UAC elevations and integrity levels do not define new Windows security boundaries, and, as such, attacks against these features aren't attacks against "security". This is all true, assuming you understand the minutae he's talking about. Distinguishing between the established Windows security architecture (the LSA, desktops, security prinicpals, ACL's, privileges, etc) and this integrity level retrofit is pretty minute, but it's accurate.

It's silly that Mark said this in this way, because a user with a Vista-based PC that has been taken-over by malicious software (that they, no doubt, installed by elevating the installer for the malware) isn't going to differentiate between breaches to the Windows security model, and attacks against UAC. What Mark says is factually correct, but isn't in sync with the types of non-technical statements coming out of Microsoft.

It's compelling, from a sales perspective, for Microsoft to make lofty and vague statements about Vista's enhanced security, while convenient for them to have technical fact to fall back on-- technical fact that the average user won't ever know is there.