UAC: Vista UAC vulnerabilities

I just found out about an important security update for Vista: KB943078. Betanews published the related article Microsoft acknowledges Vista kernel elevation vulnerability on December 14, 2007 that links to the Microsoft Security Bulletin MS07-066 - Important. Basically, a vulnerability has been found that enables a trojan to elevate itself to full administrator without the user's knowledge, thereby gaining complete control of the system. (This is what they mean when they say that UAC is not a security boundary.)

While we are on the subject of vulnerabilities, here are some other oldies worth knowing about...

PC World published the article Vista's UAC Warnings Can't be Trusted, Symantec Says on February 22, 2007. Basically this is a vulnerability that tricks a user into thinking it is safe to elevate a process. It does this by tricking the system into displaying the trusted green elevation dialog that indicates that the elevation request is coming from a trusted Windows process rather than from an unknown process (that would be displayed with a yellow/orange title bar). You can see samples of the various elevation dialogs here: Getting Started with User Account Control on Windows Vista

That was followed up by eWeek.com on May 16, 2007 with the article Researcher Reveals 2-Step Vista UAC Hack. This article shows that the theoretical vulnerability found by Symantec could actually be exploited. Remember, that this exploit is a weakness in the design of UAC so it won't be patched like was done with the critical security update above. This is a good reminder that your user population should not be given administrator privileges unnecessarily.

While we're on the topic of weakness in UAC design, you will want to have a look at ZDNet's article Hacker, Microsoft duke it out over Vista design flaw posted February, 2007. It points out the compromises made to Vista's elevation procedures when it comes to installing legacy applications. It is important to note that Vista's requirement that you must be admin to install some of these applications is less secure than XP where sometimes you had the opportunity to install products with only basic user rights.

[EDIT 22/01/2008] George Ou who blogs on ZDNet wrote a thoughtful article discussing the link above. He spoke with the two parties involved and got some good insight. Read: What the UAC 'hole' is really about

I also found another article written from the perspective of third party Vista security vendors: Reports of Vista's security weakness 'overblown'
[/EDIT]

UAC: Is Windows Vista secure?

It's the question everyone's been asking. Is Windows Vista secure? The short answer is - "NO". A more fair question is, "Is Windows Vista more secure than XP?". It also happens to be a much harder question to answer.

The short answer is, "Maybe, maybe not.".

Want to watch a senior Microsoft architect attempt to answer that question? This is a one hour interview with Mark Russinovich, Technical Fellow with Microsoft's Core OS team (I have a lot of respect for this guy - he has a lot to teach us.). The Vista security discussion starts at the 18 :45 mark. The topic of rootkits comes up at 31:30. If want to skip the deep architectural discussions or need to cut to the chase quickly, start watching at 39:40.

I have asked the question of security here because it gives me a chance to talk about UAC and Vista security at a more general level before my future articles just deal with individual pieces of technology. There are some important things for you to think about if you plan to deploy Vista in an enterprise.

I should mention that you will want to have some understanding of UAC before reading this article. For a primer on UAC, read my article UAC: An introduction to User Account Control and follow one of the first links.

To be fair, Vista has been built from the ground up with an eye to security. It isn't just User Account Control (UAC) - there are many, many features which combine in an attempt to provide security. Vista has architectural details like the integrity levels that separate the kernel, system, and users or the Address Space Library Randomization (ASLR) which makes system calls harder to find. Microsoft has also added features like Bitlocker and Windows Defender to help protect Vista. Even applications like Outlook and Internet Explorer do their part to lock down the OS.

One of the problems keeping Windows Vista from being secure is that it is the evolution of an insecure product. All new technologies must accommodate the architectures that came before. Vista must remain compatible with past applications developed for XP or risk alienating all of their customers. Not only has Microsoft had to add features like Virtualization and UAC to aid Vista with backward compatibility, but it has had to make fundamental accommodations in its architecture as well. Let's face it, Windows operating systems are general purpose platforms that try to meet the needs of home and enterprise users on countless hardware platforms - the OS must be pliable and customizable in order to make it work in each environment. It is the customizable element of Windows Vista that makes it vulnerable.

I feel strongly that Vista is not where Microsoft wants to be with security. Rather, it is a transitional OS that is leading the industry to where Windows must go. Currently, Vista must allow many program installers administrator access so they can reconfigure the OS. Vista must allow unsigned drivers to execute. Vista is unable to cordon itself off behind security boundaries but must instead put up numerous walls and gates in an attempt to confuse and slow the advance of rogue elements. Although Vista has separated itself between system and user environments, there are few applications that currently respect this division.

Let's expand this last point as an example of insecurity. Microsoft's marketing would have you believe that Vista is secure because it now makes it possible for users to operate without administrator privileges. This may be true someday, but the reality is that it isn't feasible now. While it is true that Vista can run some applications with Standard User rights instead of the Administrator rights required under XP, the truth is that there are still a high percentage of applications that require full administrator rights in order to install - or even function. Every time an installer must be elevated to admin or a user must be given local administrator rights permanently in order to use an application, rogue elements are given an opportunity to flourish. The opportunities may be fewer than with XP, but I think they are still too numerous to make any real difference today. I do expect this situation to improve in the future as applications are redesigned to accommodate the way Vista wants to lock down the OS.

It has been argued that the UAC prompts one receives when the core system is being accessed by a process will limit the power of a rogue element to function within the system. I don't give this argument much credit. I think well written trojans will arrive that can skirt many of these protections. I think a user's ability to know when to disallow elevation of a process will be spotty at best. But the biggest problem that I have is with access to data. All of Microsoft's discussions about security are very much focused on the protection of the OS. Although that is well and good, I can rebuild an OS automagically within hours - my real concern is for my data. UAC will not give me any prompts if an existing trojan begins to send all of my database files on the network to a remote pirate's server.

In my view, it is UAC itself that causes Vista security to lose points to Windows XP. In many cases, UAC requires users to enter their admin credentials (username/password) in a dialog box. The appearance of the elevation dialogs can feel unpredictable to most users. This dialog box can be easily spoofed. If a trojan creates a real looking dialog box and presents it to the administrator at plausible times, it can harvest username and password combinations and send them out to the web. This really wasn't a problem in XP because elevation to an alternate account was much more rare and in those situations it was always a user initiated action with one predictable dialog appearing.

UAC also has people and process problems that may lead to reduced security. Most of Microsoft's UAC documentation speaks of splitting the user's token between user and admin functions as a way of protecting the system. People can't be faulted if they begin to believe that one account for administrative users will be sufficient - but this isn't the case. Heed Microsoft's warning in Chapter 2 of the Windows Vista Security Guide that discusses the need for admin and user accounts to separate out an administrator's tasks. This is about the only place you will find this discussion. The process problems come when you learn how UAC elevation works. You will find that UAC wasn't really designed with Microsoft's security ethos in mind. UAC can really fight you in some situations when you use a two account model. (There will be lots of future discussion on this.) Functionally, the biggest roadblock is the loss of the Run As context menu action to the "smarter" Run as Administrator context menu action (I'll talk more about this in the future as well).

The thing that I think helps Vista score the most security points against XP, is the support it gets from Outlook and Internet Explorer. These two products are the entry points for the bulk of the attacks against our systems. These products work very hard with Vista to limit the power of rogue elements that come from either of these sources. It is Vista's architecture that makes this possible. But there are problems even here. Outlook and Internet Explorer have become so restrictive that it can be difficult for internally developed scripts to send messages or display html info. In fact, I have seen instances where Outlook and Internet Explorer have been elevated to full administrator status in order for systems to continue functioning - kind of defeats the purpose doesn't it?

In the end, I grudgingly give the security trophy to Vista for three reasons. Vista can be customized to mitigate some of its weaknesses (i.e. forcing CTRL+ALT+DELETE before every elevation). Microsoft will adjust Vista as they learn how we enterprise administrators wish to use it and we'll adapt our security policies and procedures to it as well. But the main thing Vista has going for it is that it is new and there aren't many trojans and spyware programs written to work against it yet. It will be interesting to see what the future holds.

Vista's support for multiple languages

In my article User Files Folders are Bilingual, I talked briefly about Vista's multilingual features. A coworker of mine took a Vista screenshot that I thought I should show you guys. It sums up Vista's support for languages other than English rather nicely:


This Vista OS was installed using the French language. If you view the full size image, you can see that it changes icon labels and things to the French language quite nicely. In fact, it is remarkable how much the root English OS can transform itself into a French looking OS. But presented here are some of the things that betray the underlying English OS.

If you look at the Windows Explorer window, you will see the folders you would expect to see on a French Vista OS - namely Programmes for the Program Files folder and Utilisateurs for the Users folder. But it turns out that these folders aren't really there. Windows Explorer knows to present those names because of the Desktop.ini file that each of those folders contains. The folders have a Friendly Name just like the User Files Folders do (see User Files Folders are Bilingual).

To see the real underlying name, one just has to go to a DOS CMD prompt. The CMD prompt does not interpret the Desktop.ini. You can see from the example provided that the Utilisateurs folder cannot be found but the Users folder can be. I don't know why Microsoft never saw fit to make the CMD prompt smart enough to interpret the Desktop.ini file. But it's probably a good thing they didn't because they also never made the Windows Explorer smart enough to suppress interpretation of the Desktop.ini so that the real file folders could be managed. (This was highlighted as a big issue in my article Folder Redirection: Not to the user's home directory.) It is a shame that the two views of the folders can't be consistent and that we users have to be smart enough to understand what is going on here.

Now the third example in the screenshot is something I really don't understand. Did you notice the Start Menu? When you type "C:\" in the Search Box, the start menu endeavors to show you the files and folders on the C: drive. But it doesn't show you them the way the Windows Explorer shows them to you - it chooses to show them to you the way the DOS CMD window shows them to you - without the Desktop.ini interpretation. I don't know why it does this since I would expect this GUI interface to be very much a user interface - whereas I can forgive the CMD oversight since it is often just used by administrators who hopefully have half a clue.

What's also puzzling about the start menu behaving this way, is the fact that the "Search Box" is supposed to be used to search for stuff on your computer - but it won't find the Utilisateurs folder because it doesn't interpret the Desktop.ini.

Now here's a question... If you are writing a guide for French users, which folder path would you tell users to follow?

1. C:\Programmes\...
2. C:\Program Files\...

The first choice is in the language of your users and is likely the folder name they are used to from the Windows XP days. This folder can be easily browsed to using Windows Explorer. But if the user actually types the path into the Search Box or into a CMD window, the path will be invalid.

The second choice is clearly not in the user's language and not a name they are familiar with. The user can't even browse to it since Windows Explorer doesn't display that folder name. BUT if the user types the path into a CMD window or Search Box or Windows Explorer address box, the path will be valid and succeed.

Which do you choose?

UAC: An introduction to User Account Control

It's high time that I get on with my articles about UAC. I have a lot of good info to share - so come back often to read the latest articles about UAC. Let's try to make sense of it together.

User Account Control is one of the major features of Windows Vista. Vista's UAC feature touches all aspects of the operating system and certainly has a huge impact on the user experience. It changes the way users, administrators and developers work within the environment. If you are going to work with Vista, it is important that you understand this feature.

Because the details of UAC are so diverse, it is not possible to describe them to you in one short article and leave you with a good understanding. Instead I present to you many of the best UAC articles I have found on the web.

In future articles I will build on the general information presented here. I will tackle individual aspects of UAC and discuss strategies for coping with the new paradigm as an enterprise administrator.

You will probably want to read these pages in the order I have presented them. They start with general concept and progress to in-depth analysis:

Wikipedia: User Account Control
Read this. The best introductory article on UAC. It avoids the romp through the UAC feature acronyms and gets down to the business of explaining UAC to you. It should give you a good grounding for the rest of the articles to come.

Getting Started with User Account Control on Windows Vista
This is a very nice Microsoft article that does it's best to describe how UAC manifests itself when a user or administrator wants to go about his daily tasks. It shows the different prompts one would see and provides sample actions that would trigger their appearance. Different UAC configuration choices are also discussed.

Inside Windows Vista User Account Control by Mark Russinovich
Ready for some detail? This article is quite heavy on the technical details, but if you can get through it, you will have a very good understanding of UAC.

Understanding and Configuring User Account Control in Windows Vista
This is a very long Microsoft document aimed at most IT professionals. It gives a tour of many of the UAC features from an administrator's perspective. It covers concepts like Integrity Levels, Elevation Prompts, Admin Approval Mode and Application Compatibility. It attempts to give many of the UAC features context, but often overly simplifies complex paradigms - I consider it the UAC brochure. This document is a very useful resource, but will still leave you scratching your head when you meet real world examples.

UAC - What. How. Why.
Do you have an hour? Watch this video! Microsoft's Jon Schwartz, UAC Architect, and Chris Corio, UAC Technical Program Manager, discuss in detail, the development history and architecture of UAC. This video will give you great insight into what the developers were thinking and what problems they were trying to solve. They almost get you thinking that UAC is a desirable feature ;-) The attached viewer Q&A is also very educational.

Teach Your Apps To Play Nicely With Windows Vista User Account Control by Chris Corio
Although aimed at application developers, this article is a valuable read for everyone. It is written by UAC's Technical Program Manager and provides valuable details about how and why UAC does some of the things it does.

The Long-Term Impact of User Account Control by Dr. Jesper M. Johansson
Aimed at anyone who is concerned about security, this article tells you exactly what UAC is and IS NOT from a security perspective. The points made in the article are accurate and can't be stated strongly enough. UAC is not a security boundary - use the best practices suggested to protect yourself.

Windows Vista Application Development Requirements for User Account Control Compatibility
(Also available as a downloadable Word document)
This is a very long Microsoft document aimed at developers. It takes them on a tour of UAC by covering such topics as Access Control List (ACL) Settings, User Interface Privilege Isolation (UIPI), Virtualization and UAC Architecture. It covers many of the UAC features and is therefore a very useful resource. However, despite it's length, it only just touches most topics and does not give the reader enough of an appreciation of how the features will impact their development work.

In-depth analysis of Vista UAC and the creation of CreateProcess...Elevated() APIs by Thomas Hruska
A must read for application developers and some scripting admins. This article looks at how to elevate applications that require full administrative access to the system. It discusses the ShellExecuteEx() with the undocumented "runas" verb and the much talked about manifests. You will understand the UAC Virtualization feature after reading this article. This is a very detailed in-depth article - not for the faint of heart.

PsExec, User Account Control and Security Boundaries by Mark Russinovich
Aimed at the extremely technical administrator, this is an extremely well-informed article. It discusses the UAC security model and how Integrity Levels relate to it. You will know you have a good understand of UAC if you are able to follow this article. BTW, if you are unfamiliar with PSExec, look into it - one awesome tool!

Had enough? Go forth into the world and play with UAC. See how you like it. I think you will quickly find that UAC impacts your life in some rather unexpected ways. As an enterprise administrator and scripter I have bumped into many of these undocumented "features" and behaviours.

I have learned to overcome some limitations and cope with others. In some cases I am still struggling. Perhaps we can work together to achieve workable environments that include UAC. Check back often for many upcoming articles about UAC. (I hope to continue writing two articles per week.) Feel free to ask questions or comment on any of the upcoming articles... now where should I start....

Offline Files: Doesn't sync files modified while offline

One of my most popular articles for Google searches has been Folder Redirection of database files causes corruption! Well, it turns out that the Offline Files feature isn't finished providing us with surprises.

The Offline Files feature is supposed to cache network files locally so that users still have access to them when the network is unavailable. This is invaluable for Laptop users who may wish to work on projects while traveling. Users are able to modify the documents in their local cache and have them synchronize automatically when they return to the office and connect to the network. -- That's the theory at least. 90% of our laptop users have reported failures synchronizing their files. The Sync Center reports "Access Denied" for some files and refuses to sync them.

Further investigation revealed that Offline Files was able to sync newly created files but was unable to sync pre-existing files that were modified while offline. This was traced to yet another bug in the Offline Files feature. Here is Microsoft's KB article for the bug:

http://support.microsoft.com/kb/935663

The Offline Files feature won't be usable until you incorporate the hotfix described in the article. The hotfix is expected to be part of SP1. (It's starting to look like SP1 will fix a lot of Vista bugs after all - Bravo!)

Vista deleting user profiles and data!

It's been an interesting week full of bug fixes and data loss for me. The most exciting case was when I started getting calls from various Vista users claiming that they had lost all of their user settings.

Investigation revealed that users were in fact losing their entire user profiles. All trace of their local profile was completely gone - including all of the user's local folders and files. If we hadn't been using Folder Redirection all of these users would have lost all of their data. Disastrous.

Microsoft was able to quickly find the cause of the problem. It turns out that there was a bug in the GPO "Delete user profiles older than a specified number of days on system restart". The GPO is supposed to delete user profiles from the Vista computer that have been unused for a set number of days. It turns out that the GPO simply deletes the user profiles the set number of days after the user profile was created - whether the profile is being used or not. I guess the logic picked the wrong date to look at.

Two days after resolving my problem, Microsoft posted this KB article:

http://support.microsoft.com/kb/945122

I'm glad to see them react so quickly to such a critical issue. I strongly recommend that you get the hotfix described in this article to prevent the GPO from wiping out your user's data. The fix should be released as part of SP1 - I certainly hope it is.