Fixing "LUA Bugs", Part II

Aaron Margosis' WebLog : Table of contents, Aaron Margosis' non-admin blog

Aaron Margosis' WebLog : Table of contents, Aaron Margosis' non-admin blog — Mon, 27 Mar 2006 19:38:42 GMT

PingBack from http://blogs.msdn.com/aaron_margosis/archive/2005/04/18/TableOfContents.aspx

Contourner les bugs LUA

WebLog de Stéphane PAPP [MSFT] — Mon, 27 Mar 2006 20:03:23 GMT

Suite (et fin ?) des articles d'Aaron Margosis...
Ces articles sont en anglais, mais fournissent énormément...

re: Fixing "LUA Bugs", Part II

Anon — Mon, 27 Mar 2006 22:20:04 GMT

"This may be due to developer laziness, incompetence or arrogance (or all three)"

How can you blame developers for this? Microsoft were the ones who've spoiled developers in the first place. So it was your incompetence that has caused people to neglect support for limited accounts.

re: Fixing "LUA Bugs", Part II

Aaron Margosis — Mon, 27 Mar 2006 22:52:13 GMT

Anon: I'm not assigning blame to developers for causing the entire LUA problem - there's a lot more involved (future blog post perhaps). The slap here is when an app fails to run as LUA, and the developers' "fix" is just to add a hard admin check on startup and insist that you have to be admin to run the app.

re: Fixing "LUA Bugs", Part II

Ryan — Tue, 28 Mar 2006 01:54:40 GMT

I'm curious, what are your suggestions for LUA interaction for an app that is self-updating? (It downloads both updates to the main app as well as 'plugins')

Link Listing - March 27, 2006

Christopher Steen — Tue, 28 Mar 2006 07:18:12 GMT

Access to a page's head element using ASP.NET
2.0 [Via: Scott Guthrie ]
Architecting and using ASP.NET...

re: Fixing "LUA Bugs", Part II

Jose Carlos — Wed, 29 Mar 2006 17:21:35 GMT

Hi Aaron, I found this article very interesting. There is however something I can't understand.

You said "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."

Could you please tell me why would it be easier for malware to infect ACLs on program code if they are changed?

re: Fixing "LUA Bugs", Part II

Aaron Margosis — Wed, 29 Mar 2006 17:36:35 GMT

Jose - the last "them" in that sentence refers to the program files, not to the ACLs. If you make a file modifiable by changing its ACL, then malware can infect the program file or replace it with a program file of its own choosing.

re: Fixing "LUA Bugs", Part II

Jason — Sun, 02 Apr 2006 20:14:33 GMT

Also, another useful program if you don’t trust the user with the admin password is TQCRunas. This program uses Microsoft Crypto API to securely encrypt the password in a file and will allow you to perform runas commands.

re: Fixing "LUA Bugs", Part II

Aaron Margosis — Mon, 03 Apr 2006 04:43:13 GMT

Jason, TQCRunas falls into the category I described with this text: "... 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."

re: Fixing "LUA Bugs", Part II

Aaron Margosis — Mon, 03 Apr 2006 05:00:46 GMT

Ryan - that's a tough question (re self-updating apps). Your question implies other questions - are we talking about what the guidance should be for app developers who want to write self-updating apps? Or are we talking about how IT admins should deal with existing ones out there today? (I'll assume the latter since that's most of what the Fixing LUA Bugs posts are about.) The choices would seem to be:

1. No changes - the app can't be updated;

2. No local changes - the IT infrastructure can push out the security and other required updates as needed;

3. Make ACL or other changes to allow the app - running as the user - to update itself.

#2 is the best, if you can do it. #1 introduces risk that users may run vulnerable code even after exploits start showing up - but at least the exploits won't run as admin. #3 introduces risks as described in this post.

Ultimately you need to determine what your specific exposure is to which threats, what is at risk - the costs associated with those threats, vs. the pros and cons of the alternatives.
Hope this helps!

re: Fixing "LUA Bugs", Part II

Permutor — Wed, 19 Apr 2006 12:03:24 GMT

This advices on this blog are very useful. It does not give me a clue how to solve this problem. I have set up, from scratch, a Windows XP prof SP2. I have installed Office XP SP3. The system is fully up to date with Windows update.
I have set up accounts for users to run the Office XP programs. For some reason Office XP requires that these accounts have full admin rights. It refuses to run with a LUA account. All Office programs will give a cryptic message that I traced back as error 197. I will give a free translation into english since the original is in dutch: "The operating system currently is not properly configured to run this application". There is no clue what is misconfigured, or how to fix it. There is no hint on the installation disk either. I have searched the Internet to no avail. Since the problem concerns all office programs (not just one in particular) it does not make much sense to determine from scratch which authorizations are required.
I have tried to fix it with the repair function on the Office XP disk, but it has not helped. The idea of giving the users admin rights just to run Word or Outlook does not appeal to me.
Can you help me out here ?

re: Fixing "LUA Bugs", Part II

David — Mon, 24 Apr 2006 04:29:20 GMT

Aaron:

Interesting articles, I am involved with a company at the moment that wants to move Least Privelege principles applied to it's 4000 workstations but also doesn't want to fork out the money to upgrade it's legacy apps that require admin access.

So far the most attractive option to us is that of PolicyMaker Application Security, which you mentioned in your post. Are you aware of the technical details of this program? It seems to me that modification of the process tokens would be in violation of the windows security model, or am I missing something here? I searched for how to do this and it only seems possible using NtCreateToken and NtSetInformation... Any thoughts on this?

re: Fixing "LUA Bugs", Part II

redxii — Mon, 24 Apr 2006 21:37:20 GMT

We can only hope that Vista's virtualization doesn't further encourage such behaviors.

Vista is supposed to allow a non-admin to view the clock and calendar, and not assume that just because you open that applet you want to change something, right? Are there any plans to fix this in XP? It seems rather crazy to put down a few hundred bucks just so I can view the calendar without admin or the change time privilege. Other than falsifying timestamps does allowing a user to change the time present any other security risks? The Date and Time applet is the only part of the entire OS that I can think of that is inconsistent with the behavior of the rest of the OS: If you can't do it, it's greyed out and unable to interact with it.

re: Fixing "LUA Bugs", Part II

Aaron Margosis — Tue, 25 Apr 2006 00:44:57 GMT

redxii - I wouldn't expect to see any significant changes to XP's UI at this point. But a few other things:

1. The Date&Time applet (timedate.cpl) was designed to allow the user to change the date/time, not to browse the calendar or see the pretty timezone map. It turned out that people ended up using it that way, but prior to Vista it was not designed to be used as a read-only interface. See Raymond Chen's post: http://blogs.msdn.com/oldnewthing/archive/2005/06/21/431054.aspx

2. I hope you'll find more reason to upgrade to Vista than just to view the calendar as a non-admin!

3. The main security and reliability risks involved in granting SeSystemtimePrivilege are falsifying audit logs, and breaking Kerberos.

re: Fixing "LUA Bugs", Part II

Aaron Margosis — Tue, 25 Apr 2006 00:47:55 GMT

David - I would suggest contact the vendors of the 3rd party products mentioned in order to better understand how their implementations work and whether they are suited to your environment. I will point out that both PMAS and Protection Manager do not change the process token after the process has started running, and I do not believe that either causes any Common Criteria issues.

re: Fixing "LUA Bugs", Part II

Aaron Margosis — Tue, 25 Apr 2006 00:51:50 GMT

Permutor - I have no idea what might be causing the WinXP+OfficeXP problem you're reporting. I ran Office XP every day as a non-admin until I upgraded to Office 2003, and I don't remember any breaking issues. I'd suggest making sure that while logged on as admin you have installed all the Office components you will need. The installer dialog will probably come up each time a user uses a component for the first time, but that should be only to install per-user stuff.

re: Fixing "LUA Bugs", Part II

David — Wed, 26 Apr 2006 04:22:26 GMT

Ok thanks Aaron, I will contact the company for more information.

ps. Lets see a post on the politics of LUA implementation in corporate culture :)

re: Fixing "LUA Bugs", Part II

redxii — Thu, 27 Apr 2006 19:22:06 GMT

Aaron, that is rather backwards. Outlook is cost prohibitive if you want just a calendar. Otherwise the Time and Date applet could have been reduced to atleast more than 50% its current size by just including a field to change the date in MM/DD/YYYY (depending on regional settings)

Anyway, as far Office goes, I would try doing setup /a to do an administrative install and install using that source. I tried the non-administrative install way and it asks each user to insert the office cd. Earlier office versions simply failed. An administrative install hasn't done that to me ever..

re: Fixing "LUA Bugs", Part II

richard — Sat, 29 Apr 2006 22:03:21 GMT

Not sure if this is the right place to ask this but ...

Whenever I log into a limited user account on Windows XP I get a popup dialog with:

(1) no title
(2) the word "fAIL" - spelled that way!
(3) OK button

Is this some really bad Windows message?

Or a misbehaving application?

Or some infection that has problems running under a limited user account? (this is a new system, only a week old, and noticed it the first night - anti-virus programs have not detected anything)

Windows XP
Media Center Edition
Service Pack 2
AMD Athlon 64 X2

re: Fixing "LUA Bugs", Part II

Aaron Margosis — Tue, 02 May 2006 04:14:45 GMT

richard - this sounds a lot like the question here: http://blogs.msdn.com/aaron_margosis/archive/2006/02/06/525455.aspx#582509
that I answered here: http://blogs.msdn.com/aaron_margosis/archive/2006/02/06/525455.aspx#582613

HTH

re: Fixing "LUA Bugs", Part II

AC — Mon, 08 May 2006 18:01:29 GMT

Why didn't you mention the possibility to install the offending app inside of the MyDocuments as the way to avoid "opening "c:\Program Files\blah blah" for writing, which can then infect other users? Did MSFT consider expanding possibilities of something like this as the preferred solution to #4?

re: Fixing "LUA Bugs", Part II

Aaron Margosis — Mon, 08 May 2006 18:37:48 GMT

AC - great question. That is a possibility, but there are at least two significant drawbacks:
1) Patch management becomes much more complicated;
2) The binaries then are always writable (infectable) by malware running as the user. (Infecting arbitrary executables is much more straightforward than infecting data files.) If you can do #4 without changing the ACLs on executables, then it's *probably* better to keep them in %ProgramFiles%.

re: Fixing "LUA Bugs", Part II

AC — Tue, 09 May 2006 11:48:27 GMT

Aaron, I asked you because there are more applications which can be installed without problem in MyDocuments by user himself, and he doesn't even need admin privileges for that, whereas the same installer doesn't allow the user to install to the default "Program files" (or, as a second manifestation, after the installation the user can't work with the program).
So the user is even now able to install without needing admin privileges, if he just doesn't accept the default location. And he is anyway able to run any new program.

Do you want to say that the user in fact shouldn't be able to install the new application at all if he doesn't have the admin password, even if he's the only one who uses it?

re: Fixing "LUA Bugs", Part II

Aaron Margosis — Tue, 09 May 2006 19:44:13 GMT

AC - no, I'm not saying that users shouldn't be able to - I'm just pointing out some caveats:

1) Many applications won't install correctly even to a folder the user can write to, because the installation may try to register COM/DCOM components (writing to HKCR) or write other configuration data to HKLM, etc.

2) Many organizations do not want end users installing unauthorized programs due to legal, licensing, security or compliance issues.

3) As I mentioned before, binaries that the user can write to increases attack surface - at least for that user.

Changing access control on folders vs. files

Aaron Margosis' WebLog — Tue, 20 Jun 2006 05:16:42 GMT

More info on the risks of changing access control lists to fix LUA bugs.

re: Fixing "LUA Bugs", Part II

John Bokma — Mon, 17 Jul 2006 02:39:18 GMT

Hi Aaron,

Contacting the developer of a program in order to report a LUA bug might be a huge PITA. I did twice, and on both accounts the developers came up with wonderful stories why the application misbehaved. See:

http://johnbokma.com/mexit/2005/11/09/irfanview-ini-fix.html

and

http://johnbokma.com/mexit/2006/07/14/launchy-lua-bug.html

re: Fixing "LUA Bugs", Part II

jjudeb — Thu, 27 Jul 2006 22:38:10 GMT

We're experiencing the same problem as Permutor, installing MSOffice 2003 Professional on a Citrix server. Everything works fine for Administrator, but not for limited user. Since Citrix Published Applications run under Anonymous user accounts, MSOffice cannot be used as a published application any more. Everything worked fine for years with MSOffice XP, but it's hosed with MSOffice 2003.

LUA Buglight public [pre]-release

Aaron Margosis' WebLog — Tue, 08 Aug 2006 00:01:08 GMT

"Why does Application XYZ need to run as admin?"

Changing permissions on your %windir%

The things that are better left unspoken — Tue, 05 Sep 2006 23:14:56 GMT

One way of coping with the challenges corresponding with "the principle of least administrative privilege"

Changed permissions on your %windir%

The things that are better left unspoken — Wed, 06 Sep 2006 08:39:49 GMT

On the second Tuesday of the month Microsoft introduces updates for it&#39;s products. As a system administrator

re: Fixing "LUA Bugs", Part II

Doug Deden — Wed, 27 Sep 2006 15:20:00 GMT

Permutor -

The Student Edition of Office 2003 did the same thing to me. The problem was access rights to a part of the Program Files\Common Files directory structure. I think it was MSOCache, which Office uses to install parts as needed. Even though I did a full install as admin, apparently limited users still needed to see MSOCache. I think I just gave them read-rights, but I don't have that PC handy.

Changing access control on folders vs. files

Aaron Margosis' WebLog — Fri, 16 Feb 2007 05:14:36 GMT

More info on the risks of changing access control lists to fix LUA bugs.

re: Fixing "LUA Bugs", Part II

PJ — Mon, 22 Oct 2007 17:34:16 GMT

thanks for these informations.

Reading this article i search for explanation why 'cocreateinstance' may fail when UAC is On...I did'nt find it.

did you have some ideas?

[Aaron Margosis] Most likely it's because the component you're trying to instantiate is doing something that requires admin- or admin-like permissions. Another possibility is that if you are running elevated and try to instantiate something that is registered in HKCU\software\classes, COM ignores that hive when the caller is running elevated.