Aaron Margosis' "Non-Admin" and App-Compat WebLog : Fixing LUA Bugs

LUA Buglight 2.1 released

Aaron Margosis — Tue, 03 Nov 2009 21:37:00 GMT

LUA Buglight 2.1, identifies admin-permissions issues ("LUA bugs") in desktop applications. New version supports Windows 7 (x86 and x64), Vista (x86 and x64), XP (x86 only) and corresponding Server OSes.

The download and more information is on this page:

http://blogs.msdn.com/aaron_margosis/pages/LuaBuglight.aspx

"LUA Bug" demo app

Aaron Margosis — Fri, 07 Nov 2008 16:55:00 GMT

I do a lot of presentations on how to identify and fix "LUA bugs" in applications (*), both for Windows XP and Windows Vista. I frequently use a little VB6 application to demonstrate writing to various portions of the file system and registry, write to .ini files in protected locations, restart services, explicitly check for admin rights, etc. People have asked me to post that app to my blog so that they can use it too. So here it is, including the VB6 project/source code.

As is, no support, hopefully it's self-explanatory!

Chris Jackson has a more elaborate demo app with full lab script, geared toward application compatibility tools and techniques on Vista. You can get it here.

(*) "LUA" = "limited user account", a.k.a., "non-admin", "standard user"
"LUA bugs" = application or feature of an application that 1) works when run by a member of Administrators or Power Users; 2) fails when run by a standard user; and 3) has no valid business or technical reason for requiring administrative control over the computer.

LUA Buglight 2.0, second preview

Aaron Margosis — Thu, 06 Nov 2008 17:05:00 GMT

LUA Buglight is a utility that helps identify "LUA bugs" in applications -- application features that that fail as standard user but that work as administrator. I work on it in my spare time, so progress has been slow. Attached to this blog post is the second preview version of LUA Buglight 2.0.

Main changes since the previous preview:

Single executable: all the helper DLLs, EXEs, etc., are self-extracted to your temp folder when you run the program. No need to copy lots of files around.
For Vista: the helper program that requires elevation is now signed, so you get the nicer elevation prompt. The driver file for Vista is signed as well, so startup is much faster.
Explicit check for x86 -- sorry, the current version cannot be used on 64-bit versions of Windows.
Various bug fixes.

Some of the improvements of LUA Buglight 2.0 over 1.0:

Much better Vista support
Streamlined UI and improved flow
Identifies more bugs
On XP, not restricted to using a local admin account to create the "this-user-as-admin" context
On Vista, prompts for elevation just one time per session instead of for each test
Log file names autogenerated with timestamp in the name to avoid accidental overwrite of previous logs.
User options saved to the registry.

LUA Buglight 2.0 - preview

Aaron Margosis — Fri, 13 Jun 2008 07:04:00 GMT

Attached to this blog post is a PREVIEW VERSION of LUA Buglight 2.0. LUA Buglight is a utility that helps identify "LUA bugs" in desktop applications -- the bugs that appear when the application is run as a standard user instead of as an administrator.

Some of the improvements in LUA Buglight 2.0 over its predecessor:

Much better Vista support
Streamlined UI and improved flow
Identifies more bugs
On XP, not restricted to using a local account to create the admin context
On Vista, prompts for elevation just one time per session instead of for each test
User options saved to the registry

There are more improvements and refinements that I want to make, but I think you'll find it is quite usable now. And I promised some audiences here at Tech*Ed that I would post a preview version here prior to my Friday morning session introducing LUA Buglight 2.0. :-)

Note that I haven't written up new documentation yet, and that these binaries have not been signed yet.

Update, June 14: Yes - meant to mention - LUA Buglight is designed only for x86. I'll add a processor check on startup.

Update, November 6: Removing the attachment, because the Second Preview version is now available here.

LUA Buglight updated information

Aaron Margosis — Fri, 16 Feb 2007 02:59:00 GMT

I've meant to provide more info and follow-up regarding LUA Buglight, the tool I wrote to help identify "LUA bugs". "LUA bugs" are the issues that cause a program to work only when run as admin (elevated). Here are some quick notes...

1. Internationalization: there is an issue when LUA Buglight is used on non-English systems -- the XML is ANSI-coded, but there is no processing instruction indicating what encoding the LuaBuglightReporter should use, so the Reporter may report an error if the system's default encoding doesn't match up. This will be fixed in the next version. In the meantime, the workaround is to open the resulting XML in Notepad, and add the following line at the beginning of the file:

<?xml version="1.0" encoding="windows-1252" ?>

You can then open the XML file with the LuaBuglightReporter. From everything I have heard, that fixes this particular issue. Please let me know if you still run into problems.

2. Cisco Network Assistant and a pretty cool, non-intrusive fix method: JohnCKirk asked here and here about issues he ran into testing Cisco Network Assistant v4.1. I downloaded it and tested for myself. I ran the installation program as Administrator in an up-to-date Windows XP SP2 image on Virtual PC. I then switched to a standard user account, and ran the program using LUA Buglight, using the target process name and startup folder specified in the shortcut that had been placed on the desktop. I was able to run the program using LUA Buglight without any problem. It reported two issues, both involving files called "LOCK" in a couple of its installation folders under %ProgramFiles%. In one case, it just tried to create the file; in the other case it tried to create the file, change its attributes, and delete the file.

When I ran the program without using LUA Buglight, the splash screen came up, and after a short while it just became stuck on one initialization step. Process Explorer showed that it was consuming lots of CPU, and Process Monitor showed it in an infinite loop alternately hitting an Access Denied trying to create one of the LOCK files and writing that fact to a log file in the current user's profile. I had to kill the process.

In order to create a file in a folder, the user needs to have permissions on the folder. However, changing ACLs on folders is much more dangerous than changing ACLs on files. What a lot of programs do when writing "test" files like LOCK is that they verify whether the file Create/Open succeeded, but don't verify whether the subsequent Delete succeeded. So, logged in as admin, I created the two LOCK files in the folders where the program tries to write them. I then granted the non-admin user "Read & Execute", "Read", and "Write" permissions on those files. Note that these permissions do not include the "Delete" permission. When I ran the program again as a non-admin user, it started up without a problem. As long as an admin doesn't delete those files, the non-admin should be able to run the program. The Create/Open always succeeds, and the Delete silently failing keeps the files there for the next time the user runs the program.

3. LUA Buglight limitations on Windows Vista: When I wrote LUA Buglight, I focused almost entirely on getting it to work on Windows XP and Windows Server 2003 -- the platforms most of my customers were using and probably will continue to use for a while. (US Federal government -- not always the quickest technology adopters. Some of them have rotary cell phones. :-) (Just kidding.) LUA Buglight works very well on XP and 2003. At the very end I spent some time building a version that would run on Windows Vista. It does, but with some limitations.

Windows Vista introduces Integrity Levels. With User Account Control, members of the Administrators group typically run with only Standard User rights, and most programs run at the Medium Integrity Level. When the admin user chooses to elevate a program (e.g., with the "Run as administrator" context menu option), it runs at High Integrity Level, with "Administrators" enabled in the access token, and powerful privileges like "Backup", "Debug", and "Load Driver", available for use.

When you test a program with LUA Buglight on Windows Vista, LUA Buglight launches an elevated helper process in order to get the "this-user-as-admin" token for use when the target program hits an "access denied" error with the normal token. The elevated helper process duplicates its token back to the Medium integrity LuaBuglight.exe process. However, a Medium integrity process cannot impersonate a High integrity token, so it won't help get past the access denied errors. So, before it duplicates it back to LuaBuglight.exe, the helper process marks it as a Medium integrity token. One side effect I discovered later is that the resulting token also has some of the more powerful privileges stripped. The "this-user-as-admin" token does have "Administrators" enabled, but it is a Medium integrity token and with some admin privileges missing. So, when the target program hits an access-denied or privilege-not-held error and the this-user-as-admin token is impersonated and the operation retried, it will succeed and be logged if the access-check depends on membership in Administrators or on any of the remaining privileges, but will fail if the access-check requires High IL to succeed or any of the missing privileges. If the operation fails when impersonating the "this-user-as-admin" token, the operation is not logged, and the app will see the access-denied error and possibly fail as a result.

The next version of LUA Buglight will address this, somehow -- but I haven't decided how yet.

4. Network drive mappings: There were some issues involving network drive mappings that were posted as comments to the original LUA Buglight blog post. I'm working on resolving those and will provide an update when I can.

MSDN webcast: LUA Buglight

Aaron Margosis — Tue, 10 Oct 2006 19:19:00 GMT

I'll be presenting an MSDN webcast and demoing LUA Buglight next Tuesday, October 17, 2006, 11:00am US Pacific time.

Click here for more information and to register. Make sure to install the Microsoft LiveMeeting client prior to showtime.

[Update, 18 Oct 2006] The webcast is now available for on-demand viewing here.

LUA Buglight public [pre]-release

Aaron Margosis — Mon, 07 Aug 2006 23:50:00 GMT

LUA Buglight™ is a tool I've been working on that is designed to help both developers and IT Pros (sysadmins) identify the specific causes of "LUA bugs" in desktop applications running on Windows XP, Windows Server 2003, or Windows Vista. Once the specific causes have been identified, the bugs can more easily be resolved by fixing the app’s source code, or by making configuration changes, allowing the app to work correctly for non-admin users.

I have written a number of pieces about LUA bugs and how to fix them (see list below). The problem has been that before you can fix them, you need to identify them. The available tools for doing so have been lacking. LUA Buglight exists to try to solve that problem.

LUA Buglight remains a work in progress, but you can download the current version here. The download is a .zip file containing a self-extracting executable that simply extracts its contents to a folder of your choosing. Those contents include a 34-page Word document -- please read it. It should answer many of your questions.

One important note: not every item that appears in the output indicates a bug that needs to be remediated! Before making any system changes, please refer to the following guidance:

What is a "LUA Bug"? (And what isn't a LUA Bug?)
Not every "access denied" indicates a LUA bug!
http://blogs.msdn.com/aaron_margosis/archive/2006/02/06/525455.aspx

Fixing "LUA bugs", Part I
A systematic approach for working around LUA bugs that avoids unnecessary exposure
http://blogs.msdn.com/aaron_margosis/archive/2006/02/16/533077.aspx

Fixing "LUA bugs", Part II
A systematic approach for working around LUA bugs that avoids unnecessary exposure - the "rest of the story"
http://blogs.msdn.com/aaron_margosis/archive/2006/03/27/562091.aspx

Changing Access Control on Folders vs. Files
More info on the risks of changing access control lists to fix LUA bugs.
http://blogs.msdn.com/aaron_margosis/archive/2006/06/19/638148.aspx

I’ll write more about LUA Buglight in the near future.

[Updates: Oct 2006 MSDN webcast; and Feb 15 2007 LUA Buglight updated information]

Update, November 6, 2008: LUA Buglight 2.0 Second Preview is now available here. Removing 1.0 from the download.

"Problems of Privilege: Find and Fix LUA Bugs" in TechNet Magazine

Aaron Margosis — Wed, 26 Jul 2006 00:34:00 GMT

My ramblings have now been published in a more reputable venue than blogs.msdn.com. Pick up the August 2006 issue of TechNet Magazine, or see it here on the web:

Problems of Privilege: Find and Fix LUA Bugs

BTW, in the US you can subscribe to TechNet Magazine for free:

http://www.microsoft.com/technet/technetmag/subscribe.aspx

Changing access control on folders vs. files

Aaron Margosis — Tue, 20 Jun 2006 04:57:00 GMT

This post is the fourth installment in the "Fixing LUA Bugs" series. Before reading this, you should read:

A fairly common LUA bug scenario is the application that creates and modifies files in the same folder as its executables. For example: "C:\Program Files\VendorX\AppX.exe" creating a file called "C:\Program Files\VendorX\InfoX.dat" and writing to it. What are the risks for loosening permissions on the VendorX folder rather than just the InfoX.dat file? What about loosening permissions on the folder and then re-establishing tighter permissions on the executables?

Consider the scenario of arbitrary malware having been executed by the interactively logged-on "User A" – perhaps because of a browser exploit or an IM- or email-based worm. The malware runs in the context of the logged-on user. If User A is a non-admin (and assuming no exploitable elevation-of-privilege vulnerabilities), the malware could control everything that User A sees and does, but should have no effect on other users of the computer or on the integrity of the operating system itself. For example, User A cannot install a rootkit or other malware that runs when User B logs on; cannot change User B's Start menu items or the All Users' Start menu items; cannot change system executables such as cmd.exe or apps under Program Files. The threat to consider here, therefore, is whether changing access controls for the shared app can enable the malware to compromise other users or the operating system.

Assuming User A already compromised and permissions on the AppX folder having been loosened, the risks increase as you move through the following scenarios:

AppX or its data on ComputerA is used by:	Resulting threat
… User A (a single non-admin user)	Negligible additional threat – the user's profile has already been compromised. AppX folder/files are one more thing that needs to be cleaned in order to prevent re-infection.
… multiple non-admin users	Attacker can use AppX/data as a vector to compromise other non-admin users, by causing arbitrary code to execute when AppX is used. Each user who uses AppX is affected; operating system integrity is not compromised.
… a LocalSystem service or by a member of the Administrators group (or equivalent, including Power Users)	Attacker can use AppX/data as a vector to gain admin/system privileges, by causing arbitrary code to execute when AppX is used. Entire system can be completely compromised.

It is easier to run arbitrary code by attacking executable code files than by attacking data files. "Executable code files" includes binary images such as .exe, .dll, and .ocx files, but also text files such as .cmd, .vbs, .js, .htm/.html/.mht, and even .xml (depending on how it is used). It is straightforward to directly modify executable files to include or invoke arbitrary commands of the attacker's choice.

What if access is loosened on the application folder to allow creation of files or subfolders, but ACLs are applied directly to the executable files to prevent their modification? That can prevent direct modification, which may frustrate and derail some attackers, but:

If the application folder allows creation of new folders or files, an attacker can use DLL redirection to cause an application to load and execute substituted DLLs in place of shared DLLs without touching any existing files.
Files can be affected by making changes to their directory entries in the containing folder. For example, loosened permissions on the application folder can allow the user to rename or delete a file in the folder – note that these are actually changes to the directory, not to the file – and then replace it with a Trojan.

Generally speaking, executing arbitrary code by attacking data files is less straightforward. A data file attack requires specific knowledge of the file format(s) involved, and how the application uses that data. However, it is not impossible. For example, successful exploits have used malformed image files to cause buffer overruns in image-handling libraries on various platforms, and malformed document files against various productivity applications and suites. In general, the more well-known the file formats (and application vulnerabilities) the more likely they are to be exploited. However, targeted attacks can be mounted against any vulnerable application.

It is always best to avoid loosening access control on shared resources whenever possible. So always consider:

Does the application really need access to that object? For example, if the application can't write to a log file it maintains in its application folder, does the application continue to work correctly anyway? If so, then it's not a true LUA bug, so don't try to fix it.
Is the data file accessed through the "Ini File" APIs? If so, an IniFileMapping entry might fix the problem by redirecting access to per-user registry keys. For this reason, LUA Buglight [URL coming soon!] distinguishes "Ini File" API access separately from file access issues.
The LUA shims of the Application Compatibility Toolkit may obviate the need for any access control changes.
[and other mitigations described in the earlier "Fixing LUA Bugs" posts.]

As mentioned, given the choice between loosening access for a file or for its containing folder, it is always preferable to do so for the file. However, if the file does not already exist, the application will need permission on the containing folder to create the file – you can't set permissions on an object that doesn't exist. You may be able to get around this issue by pre-creating the file and setting the necessary permissions on it. If it turns out that the application regularly deletes and then re-creates the file, a further trick that might work is to pre-create the file and grant the application user the ability to write to the file, but not to delete it. Many apps won't bother to verify that the deletion succeeded, and will clear the contents of the file on subsequent access anyway. These tricks will not work, however, for cases where the application creates a temporary, randomly-named file for edits, then deletes the original and renames the temporary file to the name of the original.

In summary:

Changing access control on shared resources should be avoided if at all possible – investigate alternatives first.
Grant the least amount of additional access to the smallest possible number of resources.
Loosening access on specific data files is greatly preferred to loosening access on folders.
Avoid loosening access on executable code files.

Fixing "LUA Bugs", Part II

Aaron Margosis — Mon, 27 Mar 2006 19:26:00 GMT

Fixing "LUA bugs", Part II

If (and only if) items #1 through #3 (a, b and c) from Fixing LUA bugs, Part I don’t allow your apps to work as normal user, then – and only then – move on to items #4 and #5, which are described in this article, along with their respective benefits and drawbacks.

#4: Loosen ACLs

The usual reason for LUA bugs is that the developers (and often, the testers) always ran as admin. They didn’t explicitly set out to require that the end-user run as admin, but things crept into the code that depended on admin access, such as writing to files in the root folder of the C: drive, in the app’s installation folder under %ProgramFiles%, or in %windir%. The app worked correctly until you ran it on your machine as a regular User. The app wasn’t designed to handle that scenario gracefully, and barfed. (See What is a LUA Bug…).

Option #4 is to change the Access Control List (ACL) on objects to grant your User the access that the program requires. Typically the objects that need tweaking will be in the registry or in the file system (if using NTFS). This must be done very carefully, though, and only after all of the more-preferred options have failed.

Constraints:

App-specific resources only: ACL changes should only ever be considered on application-specific resources, not on OS-wide resources. While it might be OK to change the ACL on %ProgramFiles%\VendorX\AppX\DataFolder, you should never change the ACL on %SystemRoot%\System32 – to loosen or to tighten access. (See KB article 885409 for more information.)

Not used by admins: Avoid changing ACLs on resources – particularly executables such as .exe and .dll files – that are ever used by administrators or services. Doing so increases the risk of elevation of privilege leading to compromise of the entire system. (Even so, the attack surface would remain far smaller than it would be with everything always running as admin.)

Avoid binaries: Avoid changing ACLs on program code (e.g., exe, dll, or ocx files) if at all possible, to prevent malware from infecting or replacing them.

Single non-admin user (ideal): Ideally, the resource should be one that is only ever accessed by a single non-admin user. If the resource is accessed by multiple non-admin users, there is increased risk of one user causing another user’s account to be compromised. As described above, if it is ever used by an admin user or a service, risks are increased further.

Least additional privilege: You should grant the least amount of additional access to the smallest possible number of resources and to the smallest possible number of users in order to allow the app to work. Granting Full Control to Everyone on a big chunk of the file system or registry should never be necessary.

Granting the additional access only to the computer’s primary user is optimal, but that may be difficult to manage across a large number of systems when each computer has a different primary user (e.g., grant MARY the permissions on one system, STEVE on another, etc). If you can define a set of users who need to use the program, add them to a group and grant the access to that group.

Another alternative to consider is to grant access to the built-in INTERACTIVE pseudo-group. This will grant the additional access only to whoever is interactively logged on at the time, without also granting any additional remote access to the resource. Note that in a terminal server or Fast User Switching scenario there can be multiple simultaneous users on the computer with INTERACTIVE in their tokens.

Benefits of this approach:

Big return on the investment of your time – most of the LUA bugs that my colleagues and I have seen revolve around file and registry permissions. This approach will probably fix a larger share of your LUA bugs than any other approach.

Drawbacks to this approach:

It’s #4 on the list for a reason. This approach allows otherwise-constrained users to change shared resources – for good or evil, and makes it easier for one user (or malware unintentionally run by that user) to affect others. If the affected user is an admin, the entire system can be compromised.

As with items #3a and 3b, it is not easy, with today’s tools, to identify precisely which resources should be opened up and by how much. (More on this in upcoming posts.)

It can be difficult to know for certain whether opening access to a resource will inadvertently expose an avenue for elevation of privilege, allowing system takeover.

#5: Run the one app with elevated privileges

As a last resort, after all else fails, consider running that one app with elevated groups and/or privileges. Some apps, for example, “address” their LUA bugs by explicitly checking for admin group membership on startup and displaying an error message insisting that you simply have to be an admin to use the program. This may be due to developer laziness, incompetence or arrogance (or all three), but these apps will be resistant to any other workarounds available to you.

Typically, this approach means running the app as admin. You could instead run the app elevated but less-than-full-admin – for example, as a member of Power Users or with a specific privilege such as SeLoadDriverPrivilege. Note, though, that with a little more work many of these other groups and privileges can still be used to take over an entire system.

Benefits of this approach:

It’s better than always running everything as admin. That’s it – that is the only benefit of this approach.

Drawbacks of this approach:

Running an app with elevated privileges exposes far more risk than any of the options described earlier. It becomes very difficult to defend the system against a malicious user or malicious software when there’s an app running as admin. A simple example: Run “Notepad” as admin, then choose File/Open – that dialog is now a little Explorer-like window that gives you full, admin-level access to the entire file system, and even the ability to launch programs as admin. That can be exploited by a malicious user, or by malware pumping keystrokes or window messages into the elevated program.

How to do it:

If you trust the user with the admin password or to otherwise make security and trust decisions:

RunAs – see "RunAs" basic (and intermediate) topics and RunAs with Explorer for more information.
MakeMeAdmin – see the original post and this follow-up. MakeMeAdmin is a batch file, so you can easily customize it to run something other than a command shell. You can also customize it to make the elevated context less than full-admin.
PsExec and Process Explorer from SysInternals offer various RunAs-like options. See Mark’s blog post for more information.
RunAsAdmin, an interesting open-source utility by Valery Pryamikov, a very smart Developer Security MVP. RunAsAdmin takes an approach a little like Windows Vista’s UAC, elevating the current user in place without requiring a password.

If you don’t trust the user with the admin password:

PolicyMaker Application Security by DesktopStandard uses a Group Policy extension to configure rules for modifying process tokens. PMAS mitigates some of the drawbacks described above. For example, it can be configured so that child processes launched by a targeted app do not inherit its modified token, and can perform granular token modification, raising (or lowering) permissions, and/or adding (or removing) privileges.
Protection Manager by Winternals (the for-profit side of SysInternals) uses a lightweight client-server application and a whitelist approach to block all untrusted applications – while also allowing applications that to have their process tokens and privileges elevated to that of an Administrator or reduced to that of a User (in cases where end users are non-Administrators or Administrators, respectively). Protection Manager also doesn’t allow a child process of an elevated app to run elevated unless it is also explicitly configured as an elevated app. Conversely, all process children of reduced privilege processes are reduced automatically (to also minimize security risk). Applications can be allowed, blocked, elevated, or reduced as specified by an administrator via Digital Signatures, Hashes, NTFS File Ownership, or Path.

Trying to "hide" the admin password:

The DesktopStandard and Winternals products determine in kernel-mode code whether, when and how to modify a process token. Passwords are not used and are therefore not at risk to exposure, and the modification decision cannot be interfered with by non-admins. By contrast, there are various tools available that perform RunAs-like operations with the admin account credentials encrypted (or sometimes just obfuscated). Even though this raises the bar and will stop some users from getting the admin creds, those passwords still have to be decrypted within the user’s security context, and so are exposed to a user with the right tools.

A frequently asked question is whether the RunAs.exe /savecred option would let one create a shortcut to run a single app as admin using a saved password and not requiring further password entry. There are several issues you should be aware of:

The credentials are not tied to any one shortcut – once the creds have been saved they can be used to start any app
While the password is securely encrypted with a user-specific key, it will still be decrypted in the user’s security context and at least briefly exposed
The /savecred option is not available on XP Home Edition.

//TODO: Discuss my thoughts about the SRP/DropMyRights approach. (Bottom line: I dislike it.)

Much thanks for help and insight for this post goes to Eric Voskuil and Kevin Sullivan of DesktopStandard, and to Mark Russinovich and Wes Miller of Sysinternals/Winternals.

Fixing "LUA bugs", Part I

Aaron Margosis — Thu, 16 Feb 2006 11:47:00 GMT

You have an application that you – or your users – need to run. It’s a normal app – it isn’t designed to perform system administration of your computer, but for some reason, it doesn’t work correctly unless it’s run from an account that has administrator-level access (see “What is a "LUA Bug"? (And what isn't a LUA bug?)”. But you don’t want your users running as admin. What to do?

The “workaround” most frequently chosen is simply to add the user to the Administrators group. Sometimes this approach is not decided by the IT department, but by some “helpful” HelpDesk technician: “Let’s see whether this fixes the problem.” The technician forgets to remove you from the Admins group, inevitably leading to another HelpDesk call within a few weeks: “HelpDesk, why is my computer running so slowly, and why are all these porn ads popping up whenever I log on?” (Answer: Because you’ve been running as admin!) Let’s just call this “workaround” a non-starter and not give it any further consideration.

Other common but sub-optimal workarounds are: 1) run the one program as administrator, or 2) run the program as a regular user, but after granting Everyone “Full Control” over the program’s installation folder and all of its registry keys under HKEY_LOCAL_MACHINE, and to all of HKEY_CLASSES_ROOT. Oh, and while we’re at it, grant the user the “Debug”, “Take ownership” and “Act as part of the operating system” privileges. These are seriously high-risk ways to get the program to run, and should be avoided.

So what do you do? In this mini-series of posts, I’ll lay out a systematic approach for working around LUA bugs that minimizes exposure. I’ll discuss approaches from most-preferred to least-preferred, with some of the pros and cons of each. By the way, while this guidance is targeted primarily to Windows XP, it will also work on Windows Vista.

#1: It is a bug – treat it like one and make the developers fix it!

This is the most preferred approach. If there is no legitimate business or technical reason for the app to require admin privileges, then failure of the app to work for a regular user account is a serious bug that compromises system security, stability and manageability. (Note: if the development team says something like “It’s mission-critical, so it has to run as admin”, or “it writes to HKEY_LOCAL_MACHINE, so it has to run as admin”, the correct response from you is, “You’re talking nonsense. Fix the bug!”)

Benefits of this approach:

Once it is fixed this way, you don’t need to carry forward any shims, tweaks or workarounds.
Developers may learn from the experience, and stop creating new LUA bugs. (Note: Developers running as admin are the #1 cause of LUA bugs!)

There are some drawbacks, though:

The expense in time and/or money may be prohibitive, particularly if you have limited resources and a lot of apps to fix. You have to consider the possibility of the app having to be rearchitected, and the possibility of new bugs being introduced in the process.
The developers and/or the source code may not be available. It may be 3^rd party code from a company that no longer exists. The developers may be in rehab. Or jail. Or working for your competitor. Or they may be working on something “more important”.

#2: Application Compatibility Toolkit

Use the LUA Mode shims of the Application Compatibility Toolkit (ACT). (File and Registry Virtualization is the equivalent solution built into Windows Vista.)

The LUA Mode shims detect attempts to write to system-wide locations in the file system and registry and silently redirect them to per-user locations.

Benefits of this approach:

It is easy to implement

Drawbacks:

The LUA Mode shims on XP often do not work (Vista’s Virtualization is a complete rewrite and will have much higher compatibility marks than XP’s ACT LUA Modes.)
The added complexity of the resulting underlying operations can make your troubleshooting more complicated when things don’t work.

The next 3 items (3a, 3b and 3c) are system changes that solve different specific issues, but share the common feature of not granting any elevated access to system-wide resources.

#3a: Copy specific HKCR keys to HKCU\Software\Classes

(Registry notations used here:

HKLM = HKEY_LOCAL_MACHINE;

HKCR = HKEY_CLASSES_ROOT;

HKCU = HKEY_CURRENT_USER)

Some background: Prior to Windows 2000, HKCR was just a symbolic link to HKLM\Software\Classes, which only Administrators can write to. In other words, operations performed on HKCR\.txt would actually occur in HKLM\Software\Classes\.txt. Windows 2000 introduced per-user registration data, so now HKCR is a merged view of HKLM\Software\Classes and HKCU\Software\Classes (which the user can write to). If a key exists in the latter, it takes precedence. So now an operation on HKCR\.txt will occur in HKCU\Software\Classes\.txt if that key already exists, otherwise it will occur in HKLM\Software\Classes\.txt as it had in the past.

The issue to fix: A number of applications write to HKCR at runtime to “reinforce” their file associations, COM registration data, etc., and raise an error if the write fails, even if the data they want to write is already there. The same data is written every time the app runs. If that same registration data were stored in HKCU\Software\Classes, then the write operations would succeed, without changing program behavior.

How to fix it: First you must identify the keys under HKCR that the application is trying to write to. (How to do that will be covered in later posts.) Export those keys to one or more .reg files (in Regedit, use File/Export, Selected branch). Using a text editor, replace all instances of

[HKEY_CLASSES_ROOT\

with

[HKEY_CURRENT_USER\Software\Classes\

and save your changes. Import the edited .reg file into the registry of the user who needs to run the program.

Benefits of this approach:

This fixes issues where applications perform operations in HKCR that should have been done only during installation.
This approach is better than loosening access control on system-wide resources under HKCR (HKLM). Malware overwriting keys under HKCU will not affect operating system components or other users of the computer.

Drawbacks:

It is not easy, with today’s tools, to identify HKCR writes as the source of LUA bugs, and exactly which keys are involved. (More on this in upcoming posts.)

#3b: IniFileMapping

Background:

Back in the days of Windows 3.x, before there was the Registry that we know and love, the OS and applications stored configuration and preference data to .ini (initialization) files, such as win.ini. Windows did and still does offer API-level support for .ini files via the “Profile” APIs (e.g., WritePrivateProfileString). Many apps (including some Windows applets) still use these APIs to try to write to .ini-formatted files, often in folders where Users are not supposed to write.

Windows NT 3.1 encouraged the migration from .ini files to the more scalable and manageable Registry, and provided a means for automatically redirecting .ini file reads and writes to registry keys. The internal implementation of the “Profile” APIs was augmented to use mappings found under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\. If a mapping for a .ini file is not found under that key, then the operation is performed in the file system as before.

The issue to fix: If access to an .ini-formatted file – via the “Profile” APIs – is the cause of a LUA bug, it can be remediated by adding a key under the IniFileMapping key to redirect access to HKCU. Note that IniFileMapping is under HKLM and requires administrative privileges to configure. The config specifics are described in the documentation for the “Profile” APIs, such as WritePrivateProfileString.

Benefits of this approach:

This approach is better than loosening access control on system-wide resources in the file system. Malware overwriting keys under HKCU will not affect operating system components or other users of the computer.

Drawbacks:

It is not easy, with today’s tools, to identify .ini-file access as the source of LUA bugs. (More on this in upcoming posts.)

#3c: SafeDisc

A number of games depend on the “secdrv” device driver, also known as “SafeDisc”, from Macrovision. The secdrv driver that ships with Windows XP is a demand-start driver, which users are not allowed to stop and start, resulting in errors when accessed by programs. There is an update, available from Microsoft and from Macrovision that configures the driver to be loaded when the system starts so that the user does not need to start it. This change allows some games to work correctly for a non-admin user.

(Note that as of this writing, the Microsoft download page for this update says that “[t]his software will not alter or patch any component on your system, it will only change the startup state of the system component…” This is actually not true – it installs an updated driver.)

Benefits: Easy to implement, and no ACL changes to systemwide resources.

Drawbacks: None, really.

Coming up in Part 2:

#4: Loosening specific ACLs, and

#5: Running the one app as admin

What is a "LUA Bug"? (And what isn't a LUA bug?)

Aaron Margosis — Mon, 06 Feb 2006 09:03:00 GMT

First, what is "LUA"?

"LUA" is an acronym that variously refers to "Limited User Account", "Least-privileged User Account", "Least User Access", and probably several other clumsy phrases that ultimately indicate a computer user account that cannot make changes that affect other users of the system or the operating system itself. In Windows, these are typically members of the built-in "Users" group; they are explicitly not members of powerful groups such as "Administrators", Power Users", or "Backup Operators", and do not hold elevated privileges such as "Load and unload device drivers," "Take ownership of files or other objects," or "Act as part of the operating system".

A "LUA bug," then, refers to an application -- or a feature of an application -- that works correctly when run with elevated privileges but fails to work for a LUA user, and where there is no technical or business reason for requiring elevated privileges. A common example is when an application saves its runtime settings to a registry key under HKEY_LOCAL_MACHINE (which is read-only to LUA users), instead of to HKEY_CURRENT_USER.

Windows doesn't allow LUA users to change the system time. That is not a LUA bug, because changing the system time has security implications with respect to auditing and to the Kerberos protocol. The fact that Windows XP doesn't allow LUA users to change the time zone is arguably a LUA bug, as is the fact that double-clicking the clock in the taskbar's notification area gives you an error message instead of a read-only view of the Date&Time applet. (Note 1: Vista is heavily focused on a more seamless LUA experience -- see the UAC blog for more info -- and the Date&Time applet is a primary target for an upgraded experience. Note 2: I wrote an earlier post about how to grant a Windows XP user the ability to change the date, time and/or time zone.)

By far, the majority of LUA bugs are due to registry and file system access. A program might try to save its settings into its installation folder under %ProgramFiles%, or it might try to open a key under HKLM for "All-Access" even if it only ever needs Read access. However, there are other types of LUA bugs: attempting to start or stop a service, load a device driver, access hardware resources directly, create or manage file shares, or even explicitly check whether the current user is a member of the Administrators group.

At the core, there are always one or more low-level operations ("API calls") that succeed when performed as admin but that fail when performed as LUA. You can see some of these yourself using tools such as SysInternals' Regmon and Filemon. However, is every one of these a real LUA bug? The answer is that it depends on how the application responds to the failure. The responses I have seen can be categorized in one of three ways:

"Fire and forget": The application invokes the operation, doesn't check the result, but doesn't depend on the operation having succeeded in order to continue working correctly. This is not a LUA bug.
"Gracefully degrade": The application invokes the operation, checks whether it succeeded, and handles failure in an appropriate way. This is not a LUA bug.
"True LUA bug": The application invokes the operation, assumes it succeeded, and depends on the operation having succeeded in order to continue working correctly. A variation on this is that the app checks whether the operation succeeded, but handles the failure inappropriately, such as by displaying an error message and falling over dead.

If you've ever monitored a GUI app running as LUA with Regmon, you've probably come across an example that could be categorized as fire-and-forget: a failed attempt to open HKLM \ System \ CurrentControlSet \ Control \ MediaProperties \ PrivateProperties \ Joystick \ Winmm for All-Access. This occurs during initialization of the joystick subsystem for the process. The specific operation fails, but it does not impact the correct behavior of your application. However, I have seen "guidance" on the web (no doubt from people misinterpreting Regmon output) claiming that to fix some particular application you need to grant the user full access to this key. No! It's not a true LUA bug. You should never need to change permissions on this key!

Before you go making wholesale changes to security settings, you should verify that you're remediating a true LUA bug and not just a phantom, and that there aren't better ways that don't increase exposure. More on that in upcoming posts.