If you just evolve XP to just be a little different, people complain that it
is XP with a new UI. If you change XP too much (as you suggest Vista is),
people complain.
If you make Windows secure, people complain. If you keep Windows relatively
insecure, people complain.
If you release a new operating system too often, people complain. If you
wait too long to release a new operating system, people complain.
Let's try to move foreward.
One thing never changes. MVP's always were and always will be
Microsoft apologists which is afterall why they are MVP's. One hand
washes the other. <wink>
If Microsoft would actually FIX Windows which has been broken for over
20 years, people would cheer. You do know that don't you?
Care to comment on the following Reality Check?
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
rogram 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.
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."
More here:
http://blogs.zdnet.com/security/?p=29&tag=nl.e589