The Platypus Developer's Corner: UAC

Showing posts with label UAC. Show all posts

Sunday, July 17, 2011

Application Manifests & Visual Basic 6

Embedding Application Manifests in Visual Basic 6 binaries is really easy. Microsoft even wrote a command line utility just for this purpose. Well, not for VB6 but for binaries in general. The Manifest Tool (mt.exe), which is included in both Visual Studio and the Windows SDK is extremely simple to use. The best part is that it handles any necessary padding and can update just about any binary with no fuss.

Here's an example command line using the naming convention of Visual Studio 2005, where the manifest filename contains the program name with ".intermediate.manifest" appended.

mt.exe -nologo -manifest "program.exe.intermediate.manifest" -outputresource:"program.exe;#1

And now for a story...

When we were first confronted with the need for manifests - specifically for triggering UAC prompts in our configuration tools written in VB6 - I performed my due diligence. I researched the topic thoroughly, I took examples of the manifests provided by Microsoft, and I tested on each and every Windows OS we supported - Windows 2000 all the way up to Windows Vista/2008.

The one thing I couldn't find was a simple way to embed the manifest in those executables, that could be easily automated. The articles I read covered GUI tools like XN Resource Editor and Resource Hacker, writing my own C/++ program using UpdateResource, a long winding route using the Resource Compiler (rc.exe) or finally just leaving the manifest as a separate file.

Even though manifests had been around since Windows XP, there wasn't a single article I could find that even mentioned the Manifest Tool. Even in the Microsoft articles I have found, there is never any mention of VB6 and the Manifest Tool together. Of course, VB6 was considered legacy by the time Application Manifests came out; so, while frustrating, I can't really blame them. I can blame my search engine skills, but that's no fun.

Anyway, all but the last option were complicated, convoluted, or required too much effort. We, of course, finally settled on that last option - using external manifests - out of necessity to get something out the door. It wasn't until we started migrating code from Visual C++ 6.0 over to Visual Studio 2005 that I noticed the mt.exe command line in the build log, which was over a year and half later. Now, along with code signing, through signtool.exe the Manifest Tool is included in much of our automated build process, and I am much happier for discovering it.

Friday, July 08, 2011

Application Manifests, UAC & Windows Vista - Part 2

Way back in the days of Windows 2000, new guidelines were introduced to improve the overall usability and security of the OS. Although, in order to maintain compatibility, none of these guidelines were actually enforced at the time. Then, when Windows Vista was released, the game changed. Those guidelines were no longer optional, but there was a backup plan.

New Guidelines for Windows 2000

Only binaries or read only files should be stored in Program Files.
Any documents or user created files should be stored in My Documents.
Temporary files should be created in the user (or system) Temp folder.
Anything else should be written to Application Data.

Now, in a perfect world, everyone would have read those guidelines and started following them. After all, there is no shortage of documentation on how to implement them, but things rarely go according to plan. Even we were not immune to this thinking. I guess it could be summed up as "Well, if Microsoft doesn't care if we do it, then why should we change?" And, you can't exactly cry foul just because you didn't read the rules, can you?

With the introduction of UAC, it was no longer possible to write to Program Files without administrative privileges, but somehow older programs still worked. This is where the the requestedExecutionLevel flag in Application Manifests comes into play. If the flag is missing from the manifest, the OS does its fancy footwork of guessing whether the program should be elevated. If the program is not elevated, then the program is run in compatibility mode. Any attempts to write to a system folder - such as Program Files or System32 - or write to a system registry hive - such as HKLM - will result in virtualization.

While you may think your program is writing to HKLM, it's not. Not really. It may look like it to you. Even to the program itself, it will appear that way, because it is actually reading from a virtualized section of the registry. This means that in your own little world, everything is working as you expected, but it is not directly affecting the OS. So, any changes you make to your little world don't affect anyone else who logs into the OS. This is one of the key points that makes UAC really work. Without this, Vista would truly be the nightmare that you hear in those Mac commercials.

Still, even with virtualization in place, some wacky things can occur. for example, there's a specific case I found with the SDelete utility provided by SysInternals, which runs in compatibility/virtualization mode. If the program is run as unpriviledged and is passed a file located in Program Files, it simultaneously finds the file and cannot find the file. It actually finds the file in Program Files, and then attempts to open a file of the same name in the Virtual Store. So, after all that, it reports a success saying the file was correctly wiped and deleted, but the file in Program Files is never touched.

User Account Control (UAC)

Application Manifests, UAC & Windows Vista - Part 1

Support for Manifest Resources continued with Windows Vista. In addition to the new Shell Common Controls library and Side-by-side assemblies introduced in Windows XP, support for High-DPI Applications and User Account Control (UAC) was added to the Manifest Resource. The most scrutinized feature of the two, of course, is User Account Control, which provided additional security to the operating system by specifying within the program what type of permission was required for using the program.

With Windows XP and lower, an administrator was always logged in as an administrator and a restricted user was always logged in as a restricted user. This meant that any program executed by an administrator would always be executed with full administrative rights. While any program executed by a restricted user would never have administrative privileges.

With the introduction of UAC, if a program required administrative privileges, such as writing to HKLM in the registry or writing to a system folder, the OS would notify the user of the required privileges before executing potentially damaging code - even when logged in as an administrative user. The OS determined this through the requestedExecutionLevel flag in the application manifest. If this flag was missing, the OS would do some fancy footwork and make a guess.

The key point here is that by embedding the required privilege within the program, a user - even a user with administrative privileges - did not have to work in a completely unprotected environment. This helps restrict access to much of the operating system when performing day-to-day tasks; and when malicious software is introduced on the machine, the restricted access given to that software should help mitigate any damage.

Vista Styles

User Account Control (UAC)

Compatibility