LUA Buglight updated information
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.