mag72

What is UAC Virtualization?

What is UAC Virtualization

Ilija Miljkovac

UAC Virtualization is an often forgotten bit of Windows history. It is one of the sleekest quick solutions to a digital problem to be created, and it is still available on Windows 10 devices just in case it is needed! In this article, we’ll be going over what UAC and UAC Virtualization are, as well as how they work, and the impact UAC Virtualization had on the digital world.

What is UAC?

If you’ve ever used a Windows device, you’ll have encountered the User Account Control or UAC prompt. At its essence, it is a request from the OS to the user for them to confirm if a given app should be allowed to have certain permissions on the device.

UAC was initially rolled out as part of Windows Vista in an effort to restrict system-wide changes to a minimum, and to allow only admin accounts to give and take away these permissions. Usually, software won’t be needing access to your system paths, because of this, Windows only allows them to do this in user context. This has the benefit of bolstering security compared to systems such as Windows XP.

In Windows Vista onwards any software that wants to write to any system path will immediately fail to execute. If a program needs this in order to function, which can happen when getting a new update, then a UAC prompt will pop up and ask the user if that software should be allowed to make the changes it wants to.

The introduction of the UAC prompt revolutionized parts of Windows security and data management. In a world without the UAC prompt, there could be a piece of software capable of writing anywhere on the device unchecked. That software would then be able to go on and damage and corrupt any files or data that the malicious agent that made it would want. It could stop other software on the device from working at the click of a button, as well as download and remove any other software from the device. In essence, it would enable malicious software to take complete control over a device. Previously, personal user data was also quite disorganized, belonging to a variety of sub-directories rather than the cohesive system it has today.

How Microsoft Adapted To UAC Issues

The issue with UAC is that it had some problems with legacy software that came from before the change and relied on some of the previous capabilities. After UAC, programs were not capable of automatically writing to folders and directories like %Windir% or system32.

Sure, programs would be able to change the app’s path for its installation and potential updates after the user agreed in a UAC prompt, however, all of the user settings and data should generally go into the user folder.

No user wants a program to call up a UAC prompt every time they start them up. Although there are still some programs that exhibit this behavior today, a well-designed piece of software won’t do this.

Some global settings are also very useful to have access to when running a program and should exist within a shareable program space to be edited, for example, %programdata%. Alternatively, having them within a user hive within the Windows registry is also perfectly fine. However, it is important to keep in mind that there should be no user-specific information in a Windows folder path.

Although the UAC is a great change, all in all, Microsoft had to be aware that what they were doing was going to introduce a large change to a system that has stayed mostly stagnant for years. App devs have been creating programs with some assumptions on what they will have access to when they run. With a change as big as the UAC, it was bound to end up breaking some stuff. These programs it broke, however, contained those that major corporations relied on to function properly. Much like any other large change, there was a transitionary period.

Despite the fact that the introduction of a way to restrict software’s ability to change crucial files is a great idea, Microsoft had to find a way to resolve its issues with legacy apps. If a piece of software was writing to user data in the app path(for whatever reason, although this stopped being common practice after the introduction of proper data organization back in Windows 2000,) it wouldn’t be able to work properly in the new system. With dozens of crucial business apps finding their start in the late ‘90s, Microsoft needed to find a way for their new system to not interfere too much with their function, or those businesses would have no choice but to avoid it. Unfortunately, simply rewriting the programs was out of the question, as it would demand a highly organized effort by hundreds of app devs at the same time.

At the time, if you had UAC-incompatible software on your device, you would have to do one of two things- either run all of it with administrative privileges, which would render any benefit gained from UAC useless. Or you could simply disable it. Unfortunately, both of these options would end up with you not benefiting from the UAC, and the 1st option would even leave your security worse off than that of Windows XP.

UAC Virtualization

Microsoft’s solution for the legacy-compatibility issue was the subject of this piece- UAC Virtualization. UAC Virtualization is essentially the process of fooling an app into thinking that it’s writing to a user path instead of a system one. When an app expects to be writing to, say “D:\Program Files\AppName” it’s actually writing to a completely different one. In that path, Windows later copies all of the program path files when the app attempts to write to them the first time.

What some might find quite odd is that this works even if the app is capable of opening your file browser. It’s going to think that everything is going swimmingly, and it found the files exactly where they were supposed to be and that it has no issues writing to them. If you take a look at what the app does from outside of it, however, you can see that what it’s doing is writing to files in the Virtual Store. There is no way for the app itself to show you the actual path that it is manipulating, isn’t that cool?

Pitfalls Of UAC Virtualization

Although UAC Virtualization is an excellent addition to the Windows lineup of operating systems, it does come with a distinct set of limits that you’ll want to be aware of in order to ascertain that it’s operating properly:

  • 32-bit Only: UAC Virtualization is only available on 32-bit apps. All AMD64 compatible programs were written after the UAC system was introduced. None of these can theoretically be written in a manner that would manipulate system files the way programs before UAC Virtualization did(although IA64 software has a different set of issues.)
  • You Need Permissions: You need to possess the ability to write to the files within the original file path. If you try to write to files when you just have read permissions, then that will bring up a variety of errors, and the software you’re trying to run will crash.
  • Non-Admin: For UAC Virtualization to apply, you can’t be running the app as administrator, the only way that UAC Virtualization will work is if you’re running the app as a standard user.
  • Disabled By Default: To take advantage of UAC Virtualization, you have to specifically enable it, as it isn’t turned on by default.

Registry Virtualization- UAC Virtualization For Registry Calls

The term Registry Virtualization refers to the use of UAC Virtualization to address registry calls. These cases are those where registry virtualization isn’t successful in case the admin can’t write to the keys being called.

Using The Proper Application Manifest Can Ensure UAC Virtualization Doesn’t Apply

UAC takes advantage of the Application Manifest file. The Application Manifest file is tasked with notifying Windows of what level of privileges the app is going to need when it runs. There are 3 options here:

  1. asInvoker: The asInvoker privilege level gives the app the same access token that its current user has.
  2. highestAvailable: Pretty self-explanatory, the highestAvailable privilege level gives the app the highest level of privileges the user running it can get.
  3. requireAdministrator: The requireAdministrator privilege level makes it so that the app can only run if the user running it has administrator privileges, or an administrator gives them to the app. This privilege level is what causes the UAC prompt to pop out.

In case the app has no record of what privilege level it will run at, then Windows will attempt to virtualize it just in case. This is another behavior that you can disable in the settings.

UAC Virtualization Worked

UAC Virtualization was mostly a success. It made it so that legacy apps kept working alongside UAC. The ability to re-route the file access requests from one path to another is an extremely elegant solution that managed to mostly erase the issue. Although many of us have at some point in our lives relied on UAC Virtualization, most of us will not have known it until years have gone by, as it is a sleek and almost invisible solution. Despite this, its impact on easing the transition of legacy apps into the new UAC world cannot be understated.

It’s Not A Windows 10 Feature And Will Most Likely Disappear

There’s a common misconception that UAC Virtualization was a feature of Windows 10. However, this is not the case, sure, UAC Virtualization exists much in the same manner that almost uncountable legacy features of Windows are still supported just in case that you run into a situation where they are necessary.

With that being said, keep in mind that UAC Virtualization is an old, and mostly redundant feature today. As it was initially made to be a short-term stop-gap to give companies time to update their software in order to fit into the shifting Windows paradigm.  The company has also been transparent with its intention to eventually remove it.

App devs for important applications of the time have been urged time and time again to change their programs so that UAC Virtualization is no longer needed. Although it is a simple and effective solution- a solution isn’t necessary once the problem has stopped existing.

Setting It Up

So, if you’ve encountered one of the edge cases where UAC Virtualization is necessary in order for it to function properly- you’re in luck.

To set up UAC Virtualization, you’ll need to go into Group Policy. Press the Windows key and type in “change security settings,” from there, you’ll need to go to Local Policies, into Security Options. Finally, at the very bottom of the list that pops up, you’ll find “User Account Control: Virtualize file and registry write failures to per-user locations”

From there on, click on the “Define this policy setting” marker, and enable it from there.

Chances are that you’ll never need to do this in order to get an actual program to work properly, however, if such a chance does pop up, you’re now equipped with the knowledge to get it functioning.

Even if not, there’s no need to pass up on fun trivia. After all, isn’t it fascinating to think about how different this interpretation of the word “Virtualization” is different from any other? Isn’t it interesting to see how such a small change within Group Policy can end up making an otherwise laborious task quick and hidden from the user’s eye?

Topics like this can really get one thinking of what else is found within the 50+ million lines of code that Windows is made up of.

Closing Words

UAC Virtualization started out as a stop-gap to enable older programs to function in a new Windows environment while they changed to fit the new UAC world. If a program expected to be able to write to paths that were deemed a security risk, then they would be fooled that they’re writing to them, while they’re in fact accessing a completely different path.

UAC Virtualization was applied not only to files but also to registry targets. The word “virtualization” is used because the folders and data don’t actually appear in the location where the app expects them, they’re only there “virtually.”

Did we miss something? Do you have a UAC Virtualization experience you’d like to share? Are there any similar topics you’d like us to cover? Leave a comment down below!