Strange logic to fix Microsoft's security problem - by annoying the users

When Vista was first released, Apple poked fun at Windows Vista for annoying the PC users with a humorous yet deadly accurate commercial. The sad part is that the message conveyed by Apple turns out to be 100% spot on and has now been admitted publicly by Microsoft's Product Unit Manager, David Cross in a presentation in the RSA Conference that they "put UAC into the (Vista) platform was to annoy users--I'm serious"

This has to be one of the most stupid act I have seen as a long term Windows developer to annoy the user to get the developers to change "the ISV ecosystem; applications are getting more secure. This was our target--to change the ecosystem." Microsoft produces SDK, tools and the Operating System and you should use those tools to change the ecosystem.

There are two statements from David Cross in this report that need a thorough analysis:

1. Most users had administrator privileges on previous Windows systems and most applications needed administrator privileges to install or run.
2. "We needed to change the ecosystem," said Cross. "UAC is changing the ISV ecosystem; applications are getting more secure. This was our target--to change the ecosystem"

Mr Cross has shown poor comprehension of figures in his rebuttal that "a myth that users blindly accept prompts without reading them."

Anyone with elementary arithematics will tell you that "Seven percent of all prompts are canceled. Users are not just saying 'yes.'" is another words of saying 93% of all prompts are NOT canceled. Then that user must be saying 'yes'. Hence "It's a myth that users click 'yes,' 'yes,' 'yes,' 'yes,'" is not a myth as substantiated (93% says 'yes') by his own research with opt-in users. With that level of intelligence it is not hard to understand why they had to annoy users rather than using innovative and technically brilliant ways to fix their problem.

Has he ever heard of using tool and assistance as the way to change them? What about changing Microsoft's own practice, which encourages that ecosystem in the first place, since Windows NT 3.1. Sadly, the same practice still persists in Vista. Now I will come to analysis the above statements.

In relation to the first statement, "Most users had administrator privileges on previous Windows systems" and I wonder whose fault is that?

Ever since Windows NT 3.1 was released, it had a security model, albeit not a very tightly enforced one. The separation of privilege account, such as Administrator, and lower privilege ones, now fashionably called Standard User account, existed.

Microsoft has never, even till today, followed what Linux and Unix, do in which Windows NT should never make the user a member of Administrator to maintain a clear separation. In NT, it up to you to create additional users and many could not bother. Hence most people just lives in the Administrator's account forever. This breeds the bad habit, that Mr Cross now finds objectionable, that has been encouraged by Microsoft in succession of Windows, even in Vista.

Microsoft should force the creation of an ordinary User's account and this should be the account user uses. Sure, they need the administrator's account to install and that's difficult to avoid. But at least they should never encourage such a bad practice in the first place. I must confess that I was a great defender of this rather silly and dangerous practice for a long time, until I read Keith Brown's message, which opened my eyes and changed my attitude and practices.

I have had lively discussion with developers and ISV in relation to adopting this good practice to ensure one's code demands the least amount of privilege and that one should be aware of the security model. The results of some of those discussions have been published in this blog.

The tightening up of the Windows Security Model was first introduced in Windows 2000, with beta version years ahead of year 2000. Windows 2000 is already obsolete and over those years, Microsoft has not provided any tools to help ISV to track down those violations. Many are oblivious violations have been committed because they are running in administrator's account. Microsoft Visual Basic 6 is a classic example where it will not run properly in LUA (Lease-Privilege User Account); it needs administrative rights to run. Microsoft provides SDK, Resource Kits and various developer's tools to enable people to write Windows programs. Microsoft could easily provide diagnostic and debugging tools or add support into their premium development tool, the Visual Studio, to help ISV and developers. Yet not one single effort has been released.

Microsoft could have add an audit support into Windows 2000 to allow users or developers to detect any malpractices; similar to the auditing the 'Privilege Use'. Yet no assistance of this kind was provided.

Now in relation to the second statement, "We needed to change the ecosystem", Microsoft has not yet demonstrated a change at all in their Windows Setup practices. I have yet to see a Vista machine whose owner is running with a Limited User Account. All the installations I have seen have been set up with users' accounts belonging to the member of Administrators.

When users are members of administrators in Vista, they are running with a split token, according to Microsoft's publication - a token used for all operation contains Standard User privilege and a token with the privilege rights, which will be used once consent is given, known as "Consent Elevation". This is known as Administrator Approval Mode (AAM). The token with the privilege rights is to permit the caller to perform "Consent elevation because the user simply has to approve the assignment of his administrative rights."

According to this paper on UAC:

Elevated AAM processes are especially susceptible to compromise because they run in the same user account as the AAM user’s standard-rights processes and share the user’s profile. Many applications read settings and load extensions registered in a user’s profile, offering opportunities for malware to elevate.

Even processes elevated from standard user accounts can conceivably be compromised because of shared state....

The bottom line is that elevations were introduced as a convenience that encourages users who want to access administrative rights to run with standard user rights by default. Users wanting the guarantees of a security boundary can trade off convenience by using a standard user account for daily tasks and Fast User Switching (FUS) to a dedicated administrator account to perform administrative operations.

This acknowledge that the elaborate scheme introduced in Vista is as susceptible to attack as the good old ActiveX installation consent process, which has been extensively exploited by drive-by-downloader, Spyware and Phishing attackers.

By annoying the customer as orchestrated by Mr Cross and forcing user to "reading them", his expert has concluded that these annoying dialog boxes

say nothing about what it will do when it executes. The executable will process command-line arguments, load DLLs, open data files, and communicate with other processes. Any of those operations could conceivably allow malware to compromise the elevated process and thus gain administrative rights.

Even with my technical knowledge, I cannot tell if consenting to the request is wise.

It does not make sense to annoy the customer. It does not make it any safer. Microsoft should help ISV and developers by giving them tools and logging facility. You have an Event log and Eventing support in Vista (don't get confused with Web Service eventing); use them!

The bottom line is: I am not against Microsoft attempting to "to change the ecosystem" and I am all for it. But to use something to create annoyance to the users as a way of forcing the ISV or developers, many of them are ignorant of the security model, is to ask your users/customers to do the work for you - unpaid of course! Microsoft you are abdicating your technical leadership.

Microsoft can and should immediately, as it is long overdue, to provide tools to help developers to locate these problems. At the moment, I have frequently use FileMon, RegMon or Process Monitor, to track down violations and all these tools are free from Microsoft. All Microsoft needs to do is to expand these tools capability to home in on the violations and report to the developers.

The current implementation of virtualizing privilege access to file and registry systems without any alerting system to the developers or users is just sweeping the problem under the carpet. In fact, such strategy often create confusion for those machine shared by many users as the Windows ceases to have Machine-wide (only one instance) and Per-User settings. All users are then permitted to alter their Program Files data or HKLM registry data as these accesses are virtualized to the user's profile area.

Microsoft has failed to bite the bullet to produce tools to help the developers. Rather than using AAM and telling "developers must assume that all Windows users are standard users, which will result in more programs working with standard user rights without virtualization or shims." why not do something about it? Why not made your Windows users standard users after Windows set up? After all it is your operating system. No wonder Apple pokes fun at you and rightly so!