Deploying Standard User Analyzer (SUA) Mitigations Enterprise-Wide

[Chris Jackson]

First posted to MSDN on Jun, 21 2007

In an earlier entry I discussed the mitigation feature of Standard User Analyzer. This is useful for testing the fixes to see if they work for you, but if they do, what happens next? Typically, you want to deploy those fixes across an organization once you have discovered something that you can fix.

First, let's discuss specifically what the mitigation feature does. As we discussed in an earlier article, it can recommend loosening ACLs. This is something you want to think long and hard about doing, as it destroys the very notion of the standard user. (A standard user can hork their session and their files, but they can't hork other people's sessions and files, nor can they hork the machine itself.) If you have decided that this is something you want to do, repeat the thinking step again, just to make sure - security decisions like this aren't to be taken likely. If you still want to do it, then your deployment option is to just script it out and deploy that script, modify the installer to set the ACLs at install time, or use a shim to loosen the directory ACLs on the installer (if you don't have an MSI to transform and you don't want to repackage). That's not what we'll be discussing here.

SUA can also recommend some shims to address issues running as a standard user, and that's what we'll talk about deploying. Shims sit between an application and Windows. Consequently, a shim can't do anything that the application itself can't do if you were to change the source code, and it doesn't fundamentally change the security of the application. If you can shim it, you have a more secure approach.

So, let's assume that you have run SUA against your application, you have detected issues, and you have brought up the list of available mitigations. If it recommends Loosen ACLs, you have unchecked this because you haven't had time to think yet. If you now click apply, SUA will create a custom shim database and install it on the local computer. You can actually find that database in %windir%apppatchcustom (its name will simply be a GUID). You may be thinking to yourself, self, I can just take that shim database and use it, right? Well, not so fast.

First, let's talk about how custom shim databases work. You can add as many as you want. You can call sdbinst.exe on as many sdbs as you would like, and we'll go ahead and look at all of them. If you only have one or two applications that require shims, then perhaps that's not so bad. However, it starts to get bad if you have more. To understand why, you can just use any old database to try something out. Compare the speed of opening up a single database and running a query on 1000 rows to opening up 1000 databases and running a query on 1 row. Which do you think will be faster? Next think about long-term management of your shim data. Will it be easier for you to open up a single file and poke around, or 1000 files? So, we probably don't want to take these things one at a time.

Given that, how can we add this valuable information to a managed, organization-wide SDB file? Well, for this, let's pop open Compatibility Administrator. When you do, you'll see, in the left hand pane, an entry for Installed Databases. If you expand this tree node, you'll see "SUA Mitigations for xxx.exe -- x/x/2007 12:00:00 am" for your application - this is the custom shim database that SUA created for you. If you expand this in the tree, you'll see an Applications node, and beneath this, you'll see "xxx.exe -- Anonymous Application modified by the Standard User Analyzer", and when you select this you'll see the list of shims applied in the right hand pane. Now you may be thinking to yourself, self, I don't want to just grab the SDB as a whole, but couldn't I just cut and paste the application into my own central custom shim database?

That's right - Compatibility Administrator supports cut and paste. From the left hand pane, right click on the application, and select cut. Then, you can go to another SDB, right click, and select paste. Why not do that, then? To discover why, just look at the right hand pane. You'll see the list of matching files. here, you have the name of the .exe you were testing. And that's it. No version information, size information, publisher information - anything. We're going to match purely on the name of the exe, regardless of version. So, never versions will get shimmed up as well - probably not something you want. And, if the name of the .exe isn't particularly distinctive, you'll also end up shimming every other application with the same name.

So, the net result is that you'll use the .sdb that SUA generated for local testing, but you're going to want to build up your own in order to deploy the sdb. Fortunately, it's fairly easy to do, so we'll do that now.

The application I was testing triggered 3 mitigations - ForceAdminAccess, LocalMappedObject, and ElevateCreateProcess. If you have already started a new shim database, then open this existing database up. If not, then Compatibility Administrator automatically gives you a blank one when you start it up. Select the New Database (1) [Untitled_1], then click the Fix toolbar button. Provide details on the application (name, vendor, and path - we don't put the path in the SDB, but we use it to look at the exe and discover what matching information is available for us to use). Click next. We don't want an OS mode, so change this from Windows 95 to None. Click next. Now, you can add these shims. With the list of shims highlighted, you can just start typing the name - we'll scroll there in the list automatically (much quicker than using the scrollbar). I added these three shims. Click next, and now you get to specify the matching information above and beyond the name. You can match on just that .exe, or on other files that will always be found in directories relative to that directory, and if you have a version number then you'll also see UPTO_BIN_PRODUCT_VERSION (and the same for file). This is helpful if all of your earlier versions have the same issue, and you don't want to have to create three separate fixes (but the shims will stop being applied when you release the next version). Once you have provided enough information to uniquely identify the application (without going crazy - the more comparisons we have, the longer it takes), click on Finish. Now, click on the Save toolbar button. If you are working with a new database, you'll be asked first to name the SDB, and second to provide a file name and path. If you are working with an existing one, it will just save.

Now, you have an SDB that includes these mitigations, as recommended by SUA. Deploying is fairly straightforward. It takes a single line of script: sdbinst.exe mycustomshims.sdb (with an optional -q). Since this is machine-wide, you have to run the script elevated, so a machine startup script is an option for doing this. You can also use SMS/SCCM to run the script. Or you could package up the SDB and a quick script into an MSI and distribute it that way. Or, any other way you can call sdbinst on the target machine with elevated privileges and point it to the SDB (which can either be pushed local as well or sitting on a network location somewhere).