Share via


LUA Buglight public [pre]-release

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!
https://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
https://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"
https://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.
https://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.

Comments

  • Anonymous
    August 07, 2006

    This morning on a computer I was setting up I was in Administrator mode.... and I plugged in a SANDISK...

  • Anonymous
    August 10, 2006
    It appears the the Local Adminsitrator account must really be a Local Account.  The ability to use a domain account that is an admin would be helpful. I agree.  Due to time limitations, I ended up prioritizing a lot of other stuff ahead of it (like writing documentation :-). -- Aaron

  • Anonymous
    August 14, 2006
    Hi SusanI was hoping to get your thoughts on our current situation. I work within the _____ industry....

  • Anonymous
    August 17, 2006
    A few weeks ago I bought a copy of Nobeltec's Tides and Currents software. Nobeltec is a subsidiary

  • Anonymous
    August 17, 2006
    L’outil d’identification de dysfonctionnements liés à l’absence de privilèges est disponible depuis le...

  • Anonymous
    August 29, 2006
    The comment has been removed

  • Anonymous
    August 30, 2006
    The comment has been removed

  • Anonymous
    August 31, 2006
    Thanks for the valuable advice.

  • Anonymous
    September 12, 2006
    Thanks for this tool - I've found it useful for a couple of old applications here (e.g. ones that write to a private ".ini" file in the Windows folder).

    However, I've had trouble getting it working with Cisco Network Assistant v4.0. Basically, that program works fine if I run it as admin, but the splash screen just sits in an infinite loop if I run it as a basic user. If I then run it inside LUA Buglight, it comes up with an error message: "Prelaunch Message Dialog - Unable to find the required startup resources".

    Anyway, leaving aside the problems with the Cisco app, this may indicate part of the Buglight tool that needs tweaking a bit?

    (I'm just about to install v4.1 of the Cisco app, and I'm hoping it will work better.) Thanks for the feedback - please continue to provide more -- good, bad or ugly is all helpful. What may be happening is that LUA Buglight is helping you get past the LUA bugs that kept it hanging at the splash screen, but then hit something else that it wasn't able to handle.  See the documentation for some of the reasons LUA Buglight might stumble. -- Aaron

  • Anonymous
    September 12, 2006
    The Ini file APIs (i.e, WritePrivateProfileString) assumes the ini file is in %windir% directory if the iniFile parameter is not a full path. Are there any reasons why Vista adopts the virtual store approach to redirect the path, instead of modifying the default behavior? Modifying the default behavior to what?  Writing the ini file to to the user's profile instead of %windir%?  That would be a major change to a well-documented and widely used feature.  Apps using an .ini file without specifying a path have been able to assume that the file would be in a shared, machine-wide location.  That would create a lot of app-compat problems.  Note that there are other ways to redirect .ini files without touching the source code (see IniFileMapping references in my blog and elsewhere).  There is also the option to change access control on the .ini file in %windir% for some scenarios to keep it as a shared resource. -- Aaron

  • Anonymous
    September 12, 2006
    Following up on my comment from yesterday, I upgraded to v4.1 of Cisco Network Assistant, but that behaved in exactly the same way. I think the problem may be that it runs in a slightly odd way - you run "prelaunch.exe", and that presumably passes information to some other program for the main app.

    Today I tried giving my user account Modify permissions to the installation folder, and when I did that I was able to run it fine. I then tried using LUA Buglight again, but that still resulted in the same error message (from the Cisco app), and the log file hadn't been able to record any registry/file access.

    The Network Assistant tool is a free download from the Cisco website (although you have to register for a free user account on their website first), so you (Aaron) might want to get a copy for your own PC so that you can test it with the Buglight app. It doesn't matter whether you have any Cisco hardware around, since the problem occurs before it gets as far as connecting to a device.

    Anyway, once I'd got this far, I then used a process of elimination to work out which particular file/folder needed special permissions. The confusing thing was that I went through every folder, and none of them had any files that were modified today. It turns out that the solution is to give Modify permissions to:
    C:Program FilesCisco SystemsCisco Network Assistantpackages
    (just that folder, not for files/subfolders). When the program runs, it creates a "LOCK" file in that folder, and then it deletes that file on exit. There is a separate "LOCK" file in:
    C:Program FilesCisco SystemsCisco Network Assistantutilities
    (0 bytes), but that one doesn't seem to be used for anything.

    I emailed Cisco about this in June, although the only vaguely related contact address I could find was the one for reporting security vulnerabilities. They came back and said that you don't need to be Admin, so I ought to open a support case with them, but we don't have a support contract with them at the moment and I was reluctant to pay them money to report their bug. Anyway, I'll email them again now that I've found the specific problem, in case they're interested.

    What I have been thinking about is that it would be good to have a central repository for this kind of info, maybe as a wiki? I've seen a few people compiling separate lists of troublesome apps, but it would be easier if all the info was in one place.

  • Anonymous
    September 30, 2006
    Hey, Aaron,
    First of all, thank you so much for all your LUA-related stuff, just want to say that it is really appreciated among us sysadmins.
    Now, the question - just recieved MS Download notifications email and it has following entry:
     
    Microsoft Standard User Analyzer
    This application compatibility tool helps developers and IT professionals diagnose issues that would prevent a program from running properly as a standard user without administrator privileges.
    http://www.microsoft.com/downloads/details.aspx?familyid=DF59B474-C0B7-4422-8C70-B0D9D3D2F575&mg_id=10043&displaylang=en

    Didn't use it yet but just wonder if it also is your child, or maybe based on Buglight idea... No, SUA is a different utility from LUA Buglight.  It does similar things, but the core approach is very different. -- Aaron

  • Anonymous
    October 10, 2006
    I'll be presenting an MSDN webcast and demoing LUA Buglight next Tuesday, October 17, 2006, 11:00am US

  • Anonymous
    October 14, 2006
    Hi! LUA Buglight is simply great. I'm using Your program on polish version of XP. Can You put Your eye on xml raport import function in LUA Buglight Reporter? That program is not accepting polish letters used in OS group names. Thank You! Artur -- Thanks.  Please contact me via the "Email" link on this page. -- Aaron

  • Anonymous
    November 13, 2006
    I've been somewhat remiss of late in my focus on what I consider to be a very important aspect of the

  • Anonymous
    November 28, 2006
    We're having trouble accessing network recources running an app through Buglight.  No matter what we do, on the Credentials tab, any drive mappings we set up show up in the bottom window as not being able to be copied to the admin environment.  We are logged into the PC as an active directory domain user ID that does have privaleges to the servers we're mapping to.  We are not using alternate credentials to map to the servers, but the mappings always appear in the alternate credentials window in Buglight.  Any suggestions on what we might be doing wrong with the drive mappings?  Thank you. How are the drive mappings being created? -- Aaron

  • Anonymous
    November 28, 2006
    We are mapping the drives using the Map Network Drive function under the Tools menu item in a Windows Explorer window.  We've tried just mapping the drive and running Buglight, and we've tried using the "Reconnect at login" option and then rebooting and logging in with the drives being automatically mapped that way.  On a side note, when we map to the drives, we are not prompted for any additional authentication.

  • Anonymous
    November 30, 2006
    I seem to have the same problem and would be interested in this information as well.

  • Anonymous
    December 04, 2006
    Checking to see if you have had a chance to look into the drive mapping issues sent on Nov. 28th.  Any info or thoughts on our problem with running apps on a server and going through Buglight on the pc's harddrive???  Any info is greatly appreciated. Haven't had a chance to really dig into it yet.  Can you send me the output from running NET USE at a command prompt?  Please use http://blogs.msdn.com/aaron_margosis/contact.aspx to send it. -- Aaron

  • Anonymous
    January 08, 2007
    This is a great utility, thanks a lot

  • Anonymous
    January 15, 2007
    L’outil d’identification de dysfonctionnements liés à l’absence de privilèges est disponible depuis le

  • Anonymous
    January 24, 2007
    The comment has been removed

  • Anonymous
    January 29, 2007
    Aaron, perfect! Thanks a lot! :) Cheers, Oliver

  • Anonymous
    February 09, 2007
    So I got this email earlier today..... Hi Susan, Blackthorne is eBay's auction management software; it's

  • Anonymous
    February 10, 2007
    Not a beer (but you may need one after using this tool), but LUABuglight will help you to track down the issues with needing admin rights on a pc to run the application - my most recent example being Timeslips...

  • Anonymous
    February 13, 2007
    for some reason I can't get this tool to work in windows 2000 Pro. Do I need XP for it to work ? The error I get when I try in 2000 is "Logon failed for local admin account (.Administrator). A required Privilege is not held by the client. (error # 1314 = 0x00000522). I am using the right password for my admin account. I Even tried setting up another local admin account and no go. Hope Im not doing something completely stupid. Thanks, Linc Linc:  No mistake on your part.  The tool will not run on Windows 2000 -- it requires Windows XP or higher.  (The mechanism that LUA Buglight uses to get the "this-user-as-admin" token requires the "Act as part of the operating system" privilege on Windows 2000, and it is not recommended to grant that privilege to any user account.  That privilege requirement was removed starting in Windows XP.) HTH -- Aaron

  • Anonymous
    February 15, 2007
    Updated information about LUA Buglight.

  • Anonymous
    February 21, 2007
    The comment has been removed

  • Anonymous
    February 21, 2007
    LUA Buglight™ is a tool to help both developers and IT Pros (sysadmins) identify the specific causes

  • Anonymous
    February 27, 2007
    Need your help to fix an issue in LUA Buglight.

  • Anonymous
    March 02, 2007
    Even though Microsoft's Windows Vista has only been release for a short time, there are already some free additions from Microsoft. Verbatim from Blake Handler's Blog (The Road to Know Where): WINDOWS VISTA GOODIES Experience Pack includes four programs

  • Anonymous
    March 02, 2007
    Even though Microsoft's Windows Vista has only been release for a short time, there are already some free additions from Microsoft. Verbatim from Blake Handler's Blog (The Road to Know Where): WINDOWS VISTA GOODIES Experience Pack includes four programs

  • Anonymous
    May 04, 2007
    I have come across an error in LUA Buglight.  I recently had a need to install the ODF Add-in for Microsoft Word (OpenOffice.org document) for one of our users.  After installing I had the user open Word (2003).  The add-in did not work.  Upon further investigation I found the add-in only works when run as an administrator.  I tried to run MS Word with LUA Buglight and it displayed an error.  It said the command completed successfully however nothing happened.  Unfortunately I do not remember the error.  If I have time I will try setting this up again however since I have just installed OpenOffice for this user to solve the problem for now I may not have time.  Time will tell ;-)  Anyway I thought I would pass along the steps used to duplicate the error in case you are interested.  I will try hard to make time to get you the error next week. The website for the ODF Converter is: http://odf-converter.sourceforge.net/ It needs .NET Framework 2.0 and the Office Compatibility Pack (for Office 2003 to read Office 2007 files) Paul - Thanks for the information.  If you get a chance, can you provide more details:  what OS were you testing on, specifics about the error you saw -- was Office raising the error, or LUA Buglight?  Did the Office app actually start? Thanks again. -- Aaron

  • Anonymous
    May 11, 2007
    I was testing on Windows XP SP2.  It appeared to be a LUA Buglight error.  MS Word did not launch. Paul:  ... and you specified the full, correct path to winword.exe, correct? -- Aaron

  • Anonymous
    May 16, 2007
    The comment has been removed

  • Anonymous
    May 17, 2007
    Sorry, I can't help but to reply to this: "Modifying the default behavior to what?  Writing the ini file to to the user's profile instead of %windir%?  That would be a major change to a well-documented and widely used feature." So, umm, making it so that all registry operations and file operations to certain areas go somewhere else instead (registry/file virtualization) isn't a change to a VERY widely used and well documented feature?  So that an app that has been writing to HKLM for years will suddenly get different copies of its data when different users run it?  You don't consider that a major change to a widely used and well documented feature??? laugh PatrickBennett:  You make a good point.  But there's a substantial difference between a transparent () redirection for legacy applications when the user would not be able to perform the operation at all, and changing the default behavior for all programs at all times.  The redirection does not apply to apps that run elevated (would be able to perform the operation), that have a Vista-compatible manifest associated with them, or for which virtualization is explicitly disabled. Yes, it is a major change in behavior, which is necessary for application compatibility reasons to accommodate the major change in Windows moving toward standard-user-privilege-by-default.  It can have undesirable side effects, particularly around application management, but apps failing to work at all is worse. () transparent = "tries real hard to be transparent" -- Aaron

  • Anonymous
    May 17, 2007
    Hi, This is the first time I am using this tool. I am using local admin ID under administrator account and domain Id under non-admin account via Citrix environment. However when I start the appplication, I get the following error Couldnt start process with current user credentials - CreateProcessWithLogonW failed : Access is denied. (Error # 5 = 0x00000005) I have also tried changing to other applications like Notepad but still get the above error. Kindly assist. Thank you Regards, Ryan

  • Anonymous
    June 10, 2007
    What's the cheapest way to make your SBS network more secure? I've said this before I'll

  • Anonymous
    June 19, 2007
    The comment has been removed

  • Anonymous
    March 22, 2008
    New Free Product from BeyondTrust Provides Enterprises with Fastest Path to Eliminating Administrative

  • Anonymous
    April 14, 2008
    The only tab that I have after executing luaBuglight (other than the app info tab) is the File System (1) tab, which shows that I'm opening .<file-name>, which is the symbolic link to my device driver, and requires GenericRead and GenericWrite access.  Could this be the reason my app won't run in LUA mode? [Aaron Margosis]  Could well be.  That item appearing in the LUA Buglight report indicates that the standard user cannot open it but that an admin can.  If the app needs to access that device interface in order to work correctly, then yes, that could be the sole reason your app currently requires admin rights.  One option would be to change the ACL on the device interface to allow the interactive user to access it (see IoCreateDeviceSecure in the DDK).  HOWEVER -- you must be exceptionally careful in the driver to prevent its turning into a vector for unauthorized elevation of privilege (EoP).  Make sure to validate all inputs for size and content before operating on it; also make sure that you're not exposing functionality that only an admin should be able to perform. If the driver access is required only for configuration and is not necessarily needed for normal use, you could factor out that part of the code and expose it only to users running with full admin rights. (BTW, the "(1)" on the tab indicates that there is one item on that page of the report.)

  • Anonymous
    April 15, 2008
    [One option would be to change the ACL on the device interface to allow the interactive user to access it (see IoCreateDeviceSecure in the DDK).] Thanks Aaron, that fixed it.  Since I'm using WDF I used WdfDeviceInitAssignSDDLString(). /Russ

  • Anonymous
    December 24, 2008
    Am wanting to use Buglight but when I unzipped 2.0 there is now documentation (user guide?) there. Where can I get the documentation?

  • Anonymous
    May 07, 2009
    No work for Windows7 7100 RC ENG x86 :-(

  • Anonymous
    August 26, 2009
    Thanks for your blog, I'm finding it extremely useful and I'm just starting to have a go with LUA Buglight. Is there anywhere I can get any documentation? It sounds as if there was documentation for version 1 but you've taken that down. I'm guessing it would be of some use at least for the version 2 preview which I'm using. Thanks