The Tail of Windows UAC

Windows systems… I’m not particularly fond of them anymore. I do believe however that the introduction of UAC, while not perfect¹, was a step in the right direction.

We’re all familiar with UAC by now; introduced in Windows Vista and got better by newer versions. While the technical details are complex, the basic concept is simple enough.

Microsoft realized that no matter how much they empathize on Principle of least privilege and advise against using administrator accounts for everyday tasks², almost all users still do so anyway. On top of that, programmers not following any guidelines, use any location they deem to be fit for their application’s settings.

A solution was needed. One that would not break compatibility with older programs, while giving programmers time to adjust to the new security model. It was also needed to give the sensation of “Administrator privilege” to those users who are so damn eager to have it all the time.

So thanks to the windows users and programmers, we ended up with an overly complicated solution for an imaginary problem³.

From the very start, the new model managed to get a bad reputation. It made the user experience more painful as it would constantly interrupted and annoyed users by the so called “UAC prompt”.

While it’s gotten considerably better over time, the bad reputation somehow stuck and now a lot of users still disable UAC as soon as they install Windows.

In return, Microsoft made it harder to truly disable UAC in recent versions of Windows (Windows 8+) and even tried to deny access to some apps (mainly Metro apps) if UAC is disabled; Which again, users found their ways around these limits.

And so the game continues…

How UAC Works

The principle behind UAC, is to always run programs as a standard user and evaluates the privilege if the application needs it.

In this model, the main difference between an administrator account and a standard user account is that the UAC prompt would not ask for an administrator password in the former⁴.

To keep compatibility with older programs, UAC virtualization is introduced. It provides legacy programs with virtualized read/write access to the otherwise restricted system resources. To also encourage programmers to update their codes, UAC virtualization is designed in a way to be disabled if a program is not deemed “legacy”.

How does Windows decide to enable UAC virtualization for a program you ask? Good question!

Here’s the list of the most important requirements:

• The program must be a 32-bit application
• No requestedExecutionLevel attribute must not be presented in its manifest (regardless of its value)
• Must not be explicitly running with administrative rights
• And couple of less-known requirements (e.g., should not be a kernel driver, should be interactive,etc)

When virtualization is activated for a program, instead of giving an access denied error, writing (and subsequent readings) to the important system folders and registry keys will be virtualized for that application.

On top of all of these, Windows also uses heuristic analysis to identify old setup files and request administrator privilege for them to be correctly installed.

And much, much more…⁵

The Tail of Incompetent Programmers

LPA Guideline

Like most other areas, Lazy Programmers Association has a strict guideline for approaching UAC, ensuring full compatibility.

It goes something like this:

1. Add the attribute requestedPrivileges with the value of requireAdministrator to the application’s manifest
2. Profit!

Standing My Ground

Recently i was in need of installing an application for a client. After doing so, i notice the program mandates administrator privilege for execution.

Neither the program nor the client was in need of full administrator access to do their job and yet one of them was not complying.

The only thing that this program needs to do, is to generate some output files. And As it turned out, it does so in the same location as the it’s executable (in Program Files).

I refused to accept this and decided to enable the otherwise deliberately disabled UAC virtualization for the program.

After ensuring the administrator elevation is not requested through shortcut settings and also the program satisfies all other UAC virtualization requirements, It was rather clear that the requestedExecutionLevel attribute was in play.

We can confirm this by using the almighty Sysinternal Suite to extract the manifest:
sigcheck.exe -m filename.exe

Manipulating Manifest

Old Way

In Windows XP, external manifest files had priority over embedded ones. So all we needed to do was to create a filename.exe.manifest in the same location as filename.exe, setup the correct manifest attributes and we were good to go (Of course back then there was no concept of UAC like we have today either).

Ever since Windows Vista however this has changed⁶ and making an external manifest file does not work if there is an embedded one. This apparently can be adjusted by a registry hack⁷. However, please note that it would be a system wide change and is generally not advised.

Mainstream Way

There are numerous tools available for manipulating resources (and hence its manifest) of an executable.

My favorite tool used to be ResEdit, but nowadays there are now too many to choose from (including Microsoft’s own Mage/MageUI).

The picture below demonstrate use of ResEdit for editing MineSweeper’s manifest:

Using resource editors on our file however, was not successful. All of them either failed to get the file’s manifest, crashed while doing so, or produced an unexecutable file afterwards.

Digging a bit deeper, I do believe now that this is because of the executable being packed by ASPack.

Hardcore Way

Instead of going to the process of unpacking the file first, I decided to do the dirty work myself.

No matter how much the file is encrypted/compressed, there are some parts of it that can’t/shouldn’t be packed. That is so because Windows components (like Windows Shell) directly access them even before execution (remember Stuxnet?), embedded manifest is one of those parts.

So i opened the file in a hex editor and searched for requestedPrivileges…and the rest is history…

Proper Way

Shimming is a technique for changing an application’s compatibility settings.

The idea is to use a tool called Application Compatibility Toolkit or ACT, to adjust Windows application compatibility settings for an executable.

As you might have guessed, this is a per Windows setting and needs to be applied for each PC the application needs to be run on. But it would eliminate the need of messing with the binary (which could very well violate its EULA).

More info is available Here.

---

1. Example ↩︎

2. Windows XP POLA guildline ↩︎

3. UAC Architecture ↩︎

4. UAC Processes and Interactions ↩︎

5. Inside Windows Vista User Account Control ↩︎

6. Source ↩︎

7. Source & detail ↩︎