File and Registry Virtualization – the good, the bad, and the ugly

With Windows Vista, Microsoft is evangelizing the use of “Standard User” accounts for most all users. You will also hear these accounts called LUA, or Least-privileged User Account. Running as LUA users will enable a much more secure environment and help to ensure that machine configurations remain stable. In order to ease the application compatibility woes that this major change is sure to generate, Windows Vista introduces a bridging technology know as File and Registry Virtualization (called affectionately “Virt” here). This technology makes it possible to run many applications as a standard user, even when the applications required either Administrator or Power User rights on Windows XP. This is accomplished by re-directing (or “Virt’ing”) application writes from secured areas of the system to a virtual store under the user’s profile. This technology is intended to make deployments of Vista less dependent on waiting for vendors to release new versions of their software that work with LUA. It isn’t designed to be used forever: in fact, Microsoft hopes to deprecate the virtualization feature in the next version of Windows after Windows Vista. The thought is that by that time, vendors and customers should have applications that work correctly in the low rights environment.

Here’s the good news first:

With “Virt”, many off the shelf and custom in-house applications will just work. No tweaks needed. Are you wondering how applications that write to “C:\Program Files” or HKEY_LOCAL_MACHINE could possible work within a low rights user account? The magic of Virt, that’s how!

When an application attempts to do something “bad” like write to an INI file like “C:\Program Files\PoorlyBehavedApp\Options.ini”, Windows will detect that the user’s token does not grant them access to save to that location. Instead, it will copy the existing file (if it already exists) to “C:\Users\<your_account>\AppData\Local\VirtualStore\Program Files\PoorlyBehavedApp\Options.ini”. It will then allow the write operation to succeed to this new file in the VirtualStore folder. Subsequent read operations for that file will always preferentially use the copy in the VirtualStore. Here’s a simplified flow chart outlining these read and write operations.

The same type of magic is used with certain parts of the registry. For example, if an application writes to “HKLM\Software\PoorlyBehavedApp\2.0\Settings”, windows will send that write operation to “HKCR\VirtualStore\Machine\Software\PoorlyBehavedApp\2.0\Settings”. In the same fashion as with the files, subsequent read operations will read from the VirtualStore preferentially. The registry store is backed by the file “C:\Users\<your_account>\AppData\Local\Microsoft\Windows\UsrClass.dat” in the same way that the classic HKCU area of the registry is backed by “C:\Users\<your_account>\NTUser.dat”.

So what’s bad about this?

All in all, this is a good thing and Virt should prove to be a great enabler of legacy applications. However, there is a dark side. For example, what happens if ISV’s and customers come to depend too much on Virtualization? Will they create proper applications that adhere to the principles of least privilege? Or, will they choose to save money now and just hope that Microsoft can be talked into keeping Virt around forever? Will new development be done properly? Or will developers continue to code the way that they always have since it will work OK anyway? As you can see, there is a very real risk that virt will “succeed too well” and just push that big app compat problem out into the future without actually forcing apps to be fixed now. In general, customers should check to see which applications are “virt’ing”, report them to the vendor and ask for new versions that are truly LUA aware. Optimally, new applications would only be purchased if they can pass the “Virt” test (not causing entries to be virtualized in the file system or registry). It goes without saying that any non-administrative application that doesn’t run without administrator privileges should not be purchased.

How about the Ugly?

Let’s take the fictitious application “PoorlyBehavedApp” as an example. This application was originally built on Windows 95. The lack of a security model on Win9x led the developers to an easy method of storing data: The INI file in the Program Files folder. Unfortunately, the developers fell prey to that classic problem of mixing user and machine data. Take this section of their Options.ini file as an example:

[Data]
Server=MyServer.MyCompany.com
Database=ImportantStuff
[Toby]
WindowX=100
WindowY=50
WindowWidth=800
WindowHeigh=900

As you can see, the database server and user preferences (in this case the last position of the application window on the screen) are saved in this same file. So, when the user Toby exits the application it will write the last window position to the file. Since Toby is not an administrator, this causes a copy of the Options.ini file to be created under his profile in the VirtualStore. So far so good, right? When Toby logs on and starts the application, he will get the proper settings. The same thing even works when Abby later logs on: her window position gets saved in her own VirtualStore since she is running as “Protected Admin”. Protected Admin is the default mode for administrators. Read our Split Token post for more on how the administrator will still have a user level token.

So where’s the problem? Here’s where it gets troublesome! Later, the IT staff needs to take the server down and wants to replace it with a new one that has a different name. The new server is MySecondServer.MyCompany.com. The IT staff uses SMS to push out a change to the INI file in “C:\Program Files\PoorlyBehavedApp”. What happens? Well, new users will work correctly. However users like Toby and Abby who have already used the application (and gotten virt’ed) will fail since their virtual copies of the INI file have not been updated! Their INI files are still pointed to MyServer.MyCompany.com. Here is a graphic showing where the user’s copy of the file would be.
At this point, you can probably see that the script in SMS just got much more complex. You probably need to iterate through the profiles on the machine and update the file in each of the VirtualStores. Testing just became more complex too since you need to have scenarios for existing users, new users, admin users, etc. However, don’t forget that this same thing can happen to the VirtualStore in the registry as well. This makes it even harder to update people correctly as there will only be one UsrClass.dat mounted to HKCR\VirtualStore. To update the other users you will need to perform some API magic and use RegLoadKey and RegUnloadKey to sequentially mount, update, and unmount each of the other user’s registry VirtualStores.

OK, so that was ugly – is there anything worse?

I’m glad you asked that! There are indeed possible scenarios that would allow an application level “Denial of Service” (DoS) or escalation of privilege. Let’s take a common example: Microsoft Word. Let’s say that there is a registry key set at “HKLM\SOFTWARE\Microsoft\Office\11.0\Word\Security”. There is a value there called “Level” and it is a DWORD of 2 (which means Medium security). This security level causes Word to prompt the user before running any macros that are either unsigned or signed with an untrusted certificate. In today’s world on Windows XP a non-admin user has no way to change that value. It is enforced, even though it is not under the true “policy” section of the registry. However with virt, it becomes possible for code running as the user to “update” this value (it will cause it to virtualize into the user’s registry VirtualStore). When the application reads the value, it will see the virtual entry. So maybe it has been changed to a 1 for “low” which will allow any macro to run with no prompt. Now security has effectively been lowered for this user. It’s important to note that this would have no affect on other users on the machine. To help combat this, Microsoft has built some API’s that will allow developers to specify certain folders and registry keys to never virtualize. There is also an extendable list of file types that will never be virtualized. In fact, MS Office will be set to not virtualize any security related keys like this. Other applications (LOB apps, third party apps, etc.) may need to make use of the API to block certain files from being virtualized too.
How about troubleshooting machines?
That’s another good question. In general, it will be a bit harder to tell what the “real” settings are for a specific user. It won’t be enough to look in their HKCU and the machine HKLM to see the settings. You’ll also need to check both of their VirtualStores (the registry and the file system) to see what settings may be hiding there. In some rare cases, it may be necessary to delete the VirtualStore to be sure of the settings the user has.

In Summary

Taken as a whole, virt is our friend. It will hopefully allow deployment of Vista in a secure manner without requiring that all of the applications be fixed to be LUA aware. Just remember to beware the dark side of the virt.

Follow Me on Twitter