Aaron Margosis' "Non-Admin" and App-Compat WebLog

Machine SIDs and Domain SIDs

Microsoft Technical Fellow Mark Russinovich’s recent post “The Machine SID Duplication Myth” confused many readers who didn’t understand the distinction between the two independent SIDs that belong to a domain-joined computer.  I’ll take a crack at trying to clarify that.

Machine and domain SIDs consist of a base SID and a Relative ID (RID) that is appended to the base SID.  Think of the base SID by itself as identifying an authority within which accounts and groups can be defined.  A computer is an authority within which local accounts and groups are defined.  The computer has a machine SID, and the local accounts and groups have SIDs consisting of that machine SID plus a RID.  For example:

SIDs (not names) are what are stored in access tokens associated with running code and in security descriptors associated with securable objects, and are what are compared by the security subsystem when performing access checks.

On a workgroup system, local accounts and groups are all there are.  Mark’s assertion is that authentication to a remote system using a local account requires a user name and password known to the remote system, and that SIDs are not used.  The only way anything resembling single sign on happens with local accounts is that if the remote system has the same user name and password that the caller is using.  SIDs are not transmitted and are not used for remote authentication.

If the computer is joined to a domain, then another SID comes into play.  The computer still has its own machine SID and its own local accounts and groups.  But it is also a member of a domain, and so it has a SID representing its computer account within that domain.  The domain is an authority within which accounts and groups (and other entities) can be defined – including computer accounts:

DEMOSYSTEM now has two separate SIDs:

• the machine SID which identifies it (locally) as an authority within which accounts and groups are defined (first row in the first table above); and
• the computer account SID within the BIGDOMAIN domain (second row in the second table).

You can see the machine SID on your computer by running Sysinternals PsGetSid with no parameters.  You can see the second SID on a domain-joined system by passing PsGetSid the computer name followed by a $:  psgetsid %COMPUTERNAME%$

Mark’s point is that SIDs must be unique within the authority in which they are used.  So while DEMOSYSTEM must have only one local account with the SID S-1-5-21-3419697060-3810377854-678604692-1000, it doesn’t matter if another computer uses the same SID to refer to a local account of its own.  However, within the BIGDOMAIN domain, there must be only one computer account with the SID S-1-5-21-124525095-708259637-1543119021-937822.  If multiple computers in the domain try to share that computer SID within the domain, problems will occur.  So while it’s OK to clone a system before it joins a domain, doing so after it joins a domain (and is assigned a domain computer account and a corresponding domain SID) will cause problems.

Hope this helps!

LUA Buglight 2.1 released

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

Utilities for Local Group Policy and IE Security Zones

Because of my work with the Federal Desktop Core Configuration, I’ve published a set of three utilities that manage Local Group Policy.  The newest of these (ImportRegPol) parses registry.pol files and can convert their content to text.  I’ve also created a utility to view and compare IE security zone settings that is particularly helpful on a system that has been locked down with Group Policy.

I also wrote a blog post on the FDCC blog describing compatibility problems caused by a widely-deployed registry hack that tries to prevent Autoplay.

Live, on the internet...

Ahoy, all -- Later this week I'll be appearing at a virtual roundtable hosted by Mark Russinovich, streaming live over the web.  The topic is Windows 7 application compatibility.  Among other things, I'll be demoing the latest (still-unreleased) updates to LUA Buglight (latest released version here).

Here are the details:

Springboard Series Virtual Roundtable

Windows 7 Application Compatibility: Your Questions Answered (Part 1)

Date:  Thursday, June 18

Time:  11:00am Pacific Time

https://ms.istreamplanet.com/springboard

Windows 7, is approaching fast and from the application standpoint is very similar to Windows Vista. We’re going to examine Windows 7 application compatibility not only from the perspective of moving from Windows Vista, but also for those coming from Windows XP. Join us to discuss the most common challenges around application compatibility when coming from a legacy operating system, why changes were made along the way, compatibility technologies inside the OS and methods for getting incompatible applications to run on Windows 7. Along the way we share tips and tricks, demonstrate free tools to analyze and fix applications and answer your specific questions about application compatibility live.

In Part 2 of this Virtual Round Table discussion (planned for later this Summer/Fall), we’ll discuss the options and approaches for using virtualization tools In depth to address application incompatibilities – including presentation virtualization, desktop virtualization and application virtualization. We’ll be sending out more details and posting information to www.microsoft.com/springboard for part 2 as the dates are finalized.

As part of the “virtual” experience, you may submit your questions about Windows 7 Application Compatibility to the panel live during the event—or submit questions in advance to vrtable@microsoft.com.

Springboard Series: The resource for Windows desktop IT professionals

FAQ: How do I start a program as the desktop user from an elevated app?

Common Vista/Win7 scenario:  the app you’ve written runs with elevated permissions, but then needs to start another program as the non-elevated desktop user.  For example, you want to display web content.  Now, you could just launch the web browser from your app, and let the web browser run as admin.  What could go wrong?  (Hint:  the correct answer will include the word “catastrophic”)

A very common mistake that programmers make is to grab a copy of the elevated, High Integrity Level access token from the current process and then “dumb it down”.  I.e., disable powerful group memberships, remove powerful privileges, and change the integrity level to Medium.  They then launch the new process with that “dumbed down” token.  This breaks for a number of reasons.

The new “LUA bug” of Vista/Win7

First and foremost, that approach makes the invalid assumption that the elevated app is running under the same user identity as the desktop user who originally logged on.  This is the new “LUA bug” of Vista and Win7.  (Refresher:  “LUA” = “limited user account”; “LUA bug” = failure that occurs when running as LUA and not administrator.  #1 cause of LUA bugs:  assumption that the end user will be an administrator.)  In Vista/Win7, everything runs as “LUA” by default, unless you specifically allow something to run elevated.  If you’re a member of the Administrators group, by default this involves a simple “consent” prompt.  The resulting app still runs as you, but with full admin rights.  If you’re not a member of Administrators, the elevation prompt requires the credentials of another account that is a member of Administrators.  The resulting app then runs as a different user.  A number of apps fail to take this second scenario into consideration.  “Dumbing down” the current process token is one example of that kind of failure.  The new program runs with reduced permissions, but not as the intended user.

There are at least a couple of other failures in that approach too, that are more obscure.  Let’s say you are a member of Administrators.  When you log on, the Windows LSA (Local Security Authority) generates two access tokens in two separate LSA-managed logon sessions.  One is the fully privileged, full-admin token; the other is the standard-user version, which is marked as linked to the full-admin token.  When you create a “dumbed-down” copy of the elevated one, the new token is still associated with the elevated session, and marked as being the “high half” of a split token.  As a result, if you start Internet Explorer with that token, Protected Mode will be disabled.  Also, if your “dumbed-down” process tries to launch an elevated app, it will simply launch the new process with the “dumbed-down” token, since it’s already marked as “elevated.”

“Enough nerditude.  Tell me what I need to do.”

So here’s one sequence that works well:

1. Enable the SeIncreaseQuotaPrivilege in your current token (sample)
2. Get an HWND representing the desktop shell (GetShellWindow)
3. Get the Process ID (PID) of the process associated with that window (GetWindowThreadProcessId)
4. Open that process (OpenProcess)
5. Get the access token from that process (OpenProcessToken)
6. Make a primary token with that token (DuplicateTokenEx)
7. Start the new process with that primary token (CreateProcessWithTokenW)

I’ve attached an example C++ project, built with VS2008 and the MFC AppWizard, and tested with x86 and x64 builds.  The meat of the sample is in RunAsDesktopUser_Implementation.cpp.  I’m sure it can be done in managed code, but that will be someone else’s project, not mine.

Caveats

Please note that there are a bunch of caveats about this approach:

• This runs the new program in the same context as the desktop shell.  If the desktop shell process is not running (crashed or intentionally terminated), GetShellWindow fails, and there is no process token to do anything with.  Also, GetShellWindow fails if the default shell (Explorer) has been replaced with a custom shell.
• If you have terminated the desktop shell and restarted it elevated (strongly discouraged), then the new process will also run elevated – as will pretty much everything else you start.
• This code assumes that it is running already elevated.  If you’re not running elevated, then there is no need for this code.  If you’re not running as admin, then the necessary step of enabling SeIncreaseQuotaPrivilege won’t work anyway.
• CreateProcessWithTokenW requires Vista or newer.  So:  this approach won’t work on pre-Vista (e.g., XP with runas); and if you want to incorporate this code in a program that can run on XP/2003, you need to use LoadLibrary/GetProcAddress to get the CreateProcessWithTokenW entry point.

"LUA Bug" demo app

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

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.

I'll be at Tech*Ed in Barcelona, Nov 3-7

The Return of PrivBar (x86 and x64)

I recently switched internet service providers, not realizing when I did that PrivBar and MakeMeAdmin would suddenly disappear from the internet when they un-provisioned my space on their servers.  Oops.

To try to compensate you for the inconvenience, PrivBar is now available once again, now in x86 and x64 versions.  So if you are running an x64 version of Windows (XP or higher), you can now use PrivBar in all Explorer and Internet Explorer windows.  (It will also tell you whether that particular instance is running 32-bit or 64-bit code.)

Note that by default on x64, Explorer.exe is 64-bit, but IE is 32-bit; but there are, in fact, 32-bit and 64-bit versions of both programs.  A 32-bit process can load only 32-bit DLLs, and a 64-bit process can load only 64-bit DLLs.  The main IE icons you see point to the 32-bit versions, because the vast majority of IE add-ons, ActiveX controls, etc., are 32-bit:  the 64-bit version of IE cannot load those ActiveX controls, so sites like youtube don't do much.

Click here for the PrivBar binaries; click here if you want the slightly-updated source code and Visual Studio 2008 project files.

Instructions:

1. Extract PrivBar.dll from the zip file and put it somewhere where all users have Read access to it.  If you're running an x64 version of Windows, extract PrivBarX64.dll to the same location.
2. At a command prompt running as admin, run
   regsvr32 path\PrivBar.dll
   where path is the folder location to which you extracted PrivBar.dll.  If you're running x64, do the same with PrivBarX64.dll.  Note that you have to be running as (fully-elevated) admin in order to do this, and that trying to register the x64 version on 32-bit Windows will fail.

No need for the extra .reg file anymore.  You can now enable the bar in Explorer or in IE by choosing View / Toolbars / PrivBar, as before.

(BTW -- MakeMeAdmin is back online, too.)

LUA Buglight 2.0 - preview

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.

Published - Security by Obscurity, and FDCC

In case I actually have any fans that are interested in things I've written outside of this blog (must be sick people)... I recently contributed a sidebar to the cover story of this month's TechNet Magazine:  Hiding in Plain Sight - Security By Obscurity.  Jesper Johansson and Roger Grimes wrote the main point/counterpoint, to which Steve Riley and I contributed further debate.  (By the way:  Roger is right.  Jesper and Steve are wrong. :-)

I've also been keeping busy helping US Federal government customers with the implementation of the Federal Desktop Core Configuration.  My fingerprints can be seen in various posts on our FDCC blog where I've published some utilities for managing Local Group Policy, and presented some webcasts, too.

Info about LUA Buglight 2.0

I recently did a TechNet webcast about the upcoming LUA Buglight 2.0.

You can view the webcast here, and download the slides here.

I'll be speaking at Tech*Ed in June

I'm speaking at Tech*Ed North America 2008, during the "IT Professionals" week, June 10-13.  I'll be presenting SIX (6) sessions, all on non-admin / least-privilege and the resulting application compatibility issues that arise.  (When I started my "non-admin" blog back in 2004, it was all about security.  Now that least-privilege has increasingly become the default, it has become much more about application compatibility.)

Specific dates/times and session numbers to be determined:

• Finding Permissions Issues with LUA Buglight 2.0
  I've been working on an update to LUA Buglight and will discuss/demo it.  (I hope to have something you can download and run by then -- can't promise, though.)
  
• Fixing "LUA Bugs" (Admin-Permissions-Required Bugs)
  Similar to the "Fixing LUA Bugs" series on my blog, but updated with more info pertinent to Vista and additional information regarding app-compat shims
  
• Identifying "LUA Bugs" (Admin-Permissions-Required Bugs)
  Comparing/constrasting Sysinternals Process Monitor, Standard User Analyzer and LUA Buglight for identifying root causes of LUA bugs
  
• Windows Vista App-Compat Topics: MIC, UIPI, Protected Mode IE
  Mandatory Integrity Control, User Interface Privilege Isolation, Protected Mode Internet Explorer, what they are and how they impact application compatibility
  
• Miscellaneous App-Compat/Architecture Topics: Terminal Services Sessions vs. Logon Sessions; Where Mapped Drives are Defined, and More
  Some really nerdy deep-dive stuff that is actually worth knowing.
  
• How We Got Where We Are: Why Windows Has Traditionally Required Admin Rights
  Vista makes a big shift in how users interact with their computers and how developers have to write code for those users.  Why couldn't "least-privilege" have been the default from the beginning?  This session explains the decisions that were made and why those decisions made sense.  (Most sessions talk about current or near-future technologies -- this is all history stuff.  I'm really looking forward to this one.)

All of them are 400-level, except the last which is a 200-level session.

Why apps have security bugs ([attempted] humor)

One reason why apps have security bugs -- because we developers were trained to focus on and typically only ever focused on how legitimate users will use the product -- we never used to have to think about misuse!

A couple of years ago I wrote up a little skit.  It’s a software developer and a Quality Assurance (QA) guy, circa 1993.  I play the developer and Steve Riley plays the QA guy.

QA Guy (imitating Newman from the TV show "Seinfeld"):  Hello, Jerry.

Dev (imitating Jerry Seinfeld, with derision):  Hello, Newman.

QA Guy:  How are you today?

Dev:  How am I?  I was fine.  But now I have a QA guy in my cubicle.  The only clearer sign I could possibly receive that my life was about to take a downward turn would be to receive an invitation to appear on the Jerry Springer show.

QA Guy:  Good guess!  I found a serious bug in your program.

Dev:  Serious?

QA Guy:  Yep.  I found that if I entered a last name of 33 characters or more, the program crashes.

Dev:  That’s serious?

QA Guy:  Yes, it’s serious.  The program crashes!

Dev:  Yeah, but it will never happen.  No one has a last name that long.

QA Guy:  Someone could.

Dev:  OK, I’ll make the buffer 40 characters instead.  That should be more than enough.

QA Guy:  Yeah, but then a 41 character name will crash it.

Dev:  So put something in the manual that says that last names can’t be more than 40 characters!  Jeez!  It will never happen, OK?  These edge cases don’t matter.

QA Guy:  Of course they do – someone could crash it on purpose.

Dev:  What?  Why would anyone do that?  First of all, our customers are paying good money for our product.  Why would they then deliberately misuse it and make it crash on purpose?  And second of all, it’s running on NetWare – it crashes all the time on its own anyway, without any help!

QA Guy:  Well, that’s true – maybe we ought to switch to Windows NT. (laughs)

Dev:  (laughs) Oh, yeah, Windows NT 3.1, there’s a pillar of stability.

QA Guy:  Uh huh – and performance.  (laughs)  What a joke!

Dev:  Yeah.  But you know, I’m seeing more RFPs lately that specify that "the server platform must include Solitaire".

QA Guy:  Ha ha!  Windows NT will never amount to anything.  A dozen years from now no one will even remember that it ever existed.

Dev:  Yep.  The future obviously belongs to NetWare. 
OK, so are we done here with this so-called bug of yours?  No one’s going to crash the server on purpose, OK?

QA Guy:  Sure they would.  They could take advantage of your buffer overrun to inject code into the system.

Dev:  Oh, now this is an advance in computing that I was hitherto completely ignorant of.  I’ve seen computers that ship with monitors, and keyboards, and even tape backup, but I had never heard of one that ships with a syringe!

QA Guy:  It goes like this:  The attacker sends more data than your buffer can hold, thus overwriting the return address on the stack with a pointer back into the buffer, which now contains malicious code sent by the attacker.  The attacker now runs code of his choosing on your server.

Dev (stares at QA guy for a while, before replying):  I think that hair dye has leached into your brain.  Gee you know, it’s hard enough to get our code deployed – maybe we should use “code injection” instead.  Look, Steve, we’ve got a ton of features we still have to implement and a ridiculous deadline.  The server’s only got 2MB of RAM – we can’t afford the time to code up all these extra checks, and we can’t absorb the performance penalty of running them either.  This isn’t a bug.  The program works as designed.  If you want to go find real bugs, why don’t you go after that new guy we hired, Jesper Jo-whatever-his-name-is.

How to cleanly stop Explorer.exe on Windows Vista

This is the first time I have blogged here about something other than running with least privilege. It's about a neat trick, though, that can be useful for some people.

If you need to shut down the main Explorer process, you could just kill it from Task Manager or Process Explorer. But undesirable and unpredictable things can happen when you abruptly kill any process, particularly one as central as Explorer.

In Windows XP, you can get Explorer to exit cleanly by getting to the shutdown dialog (e.g., Start / Turn Off Computer, or Start/Shutdown), then hold down the Ctrl+Alt+Shift keys and click the "Cancel" button. (Ref: JeffDav's blog.)

In Windows Vista with its standard Start Menu, click on the Start button. Hold down Ctrl+Shift and right-click on any empty area of the menu or on the power/lock buttons at the bottom of the right half of the menu. One of the context menu choices is "Exit Explorer". Choose this and the main Explorer process will cleanly shut itself down. (Thanks to Mike Sheldon and Raymond Chen for this tip.)

If you are using the "Classic Start Menu" option in Vista, the XP Ctrl+Alt+Shift+Cancel method still works.

OK, so chances are right now you're looking at nothing but wallpaper and the Sidebar and wondering, "What do I do now?" There's no Start menu anymore, and Win+R doesn't display the Run dialog. Answer: press Ctrl+Shift+Esc. This starts Task Manager. In Task Manager, choose "File / New Task (Run)", type "Explorer" and click OK. The shell will come back to life.

Note that on both Windows XP and Windows Vista, only the "main" Explorer process exits – that is, the process that manages the Start menu, taskbar, and desktop. With default settings, all Explorer folder windows are managed by that process as well, and so they will close too. However, if you have configured Explorer to "launch folder windows in a separate process", then those folder windows will not close when you apply this trick. Furthermore, when I tried this on Windows XP, I needed to manually close all those folder windows before running a new instance of Explorer would display the taskbar, etc., instead of just displaying yet another folder window.

Why is this hidden nugget even there? Its purpose is to help developers and testers who work on shell extensions to be able to stop and restart Explorer quickly and cleanly without having to log out.

Obviously, though, this trick can also be used to launch Explorer elevated. If you've exited the shell process and start Explorer from an elevated context, the entire desktop shell will run elevated. I cannot say this without adding caveats. If you do this, everything you start from this point on will run elevated. Shell extensions will run elevated, including the ones with serious security flaws. If you shut down Explorer again, any child processes that were launched will continue to run elevated, including browsers, IM clients, etc., with all the risk that incurs. IE Protected Mode does not operate when IE is running elevated. Less important but also significant is that any processes running at Medium IL will not be able to interact with the elevated shell – for example, to display taskbar notification icons. In general, because Explorer was neither designed for nor tested with this kind of elevated execution, you should not assume that anything will work correctly, including something as fundamental as user logoff. If you really need an elevated Explorer window on Vista, you can try the unsupported trick I described in this post instead of elevating the entire shell.