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.
Comments
Anonymous
February 15, 2007
PingBack from http://blogs.msdn.com/aaron_margosis/archive/2006/08/07/LuaBuglight.aspxAnonymous
February 15, 2007
Hi Aaron - thanks for checking into that for me. One other issue I've noticed recently is that you have to enter a password for both accounts (admin and non-admin). In other words, even if those accounts don't have passwords defined, the LUA Buglight tool says "Credentials incomplete", and won't run. There's a fairly simple workaround (i.e. assign passwords!), but is that essential from a technical point of view? (For instance, we have guest PCs at my company, where the local admin account has a password but the limited user accounts don't.) JohnCKirk: Technically, kind of yes, except that (by default) local accounts without passwords cannot be used for anything except interactive logon. I'd have to check, but I don't think the accounts could be usable in this scenario without turning off the security policy (which I don't recommend doing). -- AaronAnonymous
February 22, 2007
this might work as a workaround for your drive issues. http://www.windowsconnected.com/blogs/joshs_blog/archive/2007/02/20/windows-vista-tip-enabledlinkedconnections.aspx Josh, thanks. Two things, though: 1. That applies only to Vista; and 2. LUA Buglight is designed not to require nor make permanent settings changes to the target system. -- AaronAnonymous
March 12, 2007
As a quick follow-up on the Cisco Network Assistant issue, my previous problems with LUA were my own fault - I'd forgotten to change the startup folder to be the main folder rather than the "prelaunch" subfolder. Sorry about that. Meanwhile, Cisco have released a new version of the tool (v5.1) which is something of a mixed blessing. On the one hand, if you run it as a limited user then it now gives you an error message (rather than going into an infinite loop). This message says: -- Begin quoted message -- Read/write access problems: Access is denied ======================================= Note: Read/write access is required for user home directory and installation directory: C:Documents and Settingsjkirk C:Program FilesCisco SystemsCisco Network Assistant ======================================= -- End quoted message -- I tried your fix for the LOCK file, but unfortunately it's also doing the same thing with a temporary file, and this seems to be a randomly generated name (i.e. different each time). The first time I ran the program, the file was "tempFile63013796062581692271173702585959220391179812494596", and the second time it was "tempFile47197921121043939101173703104252836960705251599367". This looks as if Cisco are deliberately trying to stop this kind of workaround, and make sure that you do have full permission to that folder, although I can't see why. Anyway, I agree with you that assigning folder-level permissions isn't ideal, but in this case I think it's the only solution. You're right both that changing the folder permissions is unfortunate and that given the random filename, it may be the only way to get it to work. If you're in contact with Cisco's support organization, perhaps you could point them to this blog post. -- AaronAnonymous
December 06, 2007
Aaron, Want to thank you for your amazing LUA Buglight tool. Saved us big time today!Anonymous
February 27, 2008
The comment has been removedAnonymous
April 07, 2008
08/04/2008 Jai besoin dinformation sur ce produit car jai exécuté plusieurs téléchargement ex: Platform SDK for windows server 2008 précédemment 2003 et Débuging tool ainsi que service pack 1 32 bits. Cest pourquoi j`aurais besoin de ces informations le plus rapidement possible une semaine tout au plus pour que je puisse me remettre a continuer a amiliorer mon ordinateur. Je vous souhaite bonne nuit a Quebec il est 01h37. Mercie. Alain Beaulieu [Aaron Margosis] My French isn't that good anymore and Altavista translations doesn't help much here, but I get the impression that your comment has nothing to do with the subject of this blog post. Please post again (in English, please) if I am mistaken.Anonymous
April 11, 2008
First of all, thanks for a cool tool! How would you contrast it to existing tools, such as Application Verifier's LUA emulation, or Application Compatibility Toolkit? Another thing I encountered is that the tool fails to work for 64-bit processes. The error seems to come from the Detours DLL, which is probably a 32-bit image so it can't be loaded into the target 64-bit process...Anonymous
September 18, 2008
Aaron, We were using this tool on an application and received the following exit code: 0xc0000022. The Viewer doesnt show any files/keys to be modified when you launch the viewer. I can run the application as an administrator but not as a non-admin. Some google'ing on the exit code suggested the msvcp71.dll may not be registered. Ideas?Anonymous
December 28, 2009
The comment has been removed