Deploying Standard User Analyzer (SUA) Mitigations Enterprise-Wide

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).

Comments (12)

  1. MC says:

    Hello, I am Using SUA in order to test an application. The recommended mitigations only include Loosen ACLs

    I have applied this mitigation but a sdb is not created at the %windir%apppatch

    What do you suggest in order to be able to apply this mitigations enterprise-wide?

    Thanks in advance


  2. cjacks says:

    The loosen ACLs mitigation should be considered a last resort – there are other options to try first. What this does is actually loosen the ACLs on that directory – it doesn’t apply shims. Specifically, it will modify the directory to allow the Everyone group full control. You can see the security issue that presents, particularly if you pick up something like the Program Files or Windows directory. While it will accurately fix the issue it’s intended to fix, there are more secure ways to do so.

    If you don’t need to share data between users, then I would try CorrectFilePaths instead. Redirect it to a per-user location. This assumes that File and Registry virtualization didn’t already fix the issue (this mitigation doesn’t discriminate on this – it may already just work with this built-in mitigation).

    If you have determined that you have to loosen ACLs, and your security review determines that you don’t undermine the purpose of running with least privileges by doing so, then you’d have to write your own script to deploy this – you can just invoke icacls to do so. It may also be better to just run as admin for this particular application than to loosen ACLs, depending on what the issue is.

    Hope this helps.


  3. MC says:

    As a matter of fact your answer helped a lot, thanks!


  4. MC says:

    Is there a way to undo the mitigation I have already applied for the Loosen ACLs?

    Thanks again!


  5. cjacks says:

    Unfortunately, there is no undo feature in the current version of SUA. You’d have to look at the mitigation after analyzing again to see which directories we modified, and then set them back. Wish I had a better answer…



  6. MC says:

    What about uninstalling the application I have tested and reinstalling it? Would the Loosen ACLs will go back to normal?


  7. cjacks says:

    It’s not tied to the installer at all – it’s just applied to the file system directly and immediately.

    Of course, if uninstalling it deletes the directory that had its ACL changed, then I suppose it would be reverted to normal by virtue of how that works, but if it modified something higher up than it really wouldn’t.

  8. Supriya says:

    What is the use of symbol path in SUA? While launching the application through SUA the symbol path which comes automatically,is that the defauly symbol path or should we give a path?

    What is a Stack trace?How it is useful in SUA?

  9. Supriya says:

    What are the new features and functionalities in SUA?

  10. cjacks says:


    The symbol path is useful when you have a developer examinging the application to change the code to fix the application. If the application is written in native code, the symbols will allow you to translate between wherever in memory the application code is at the moment, and the exact method in the code that requires elevated privileges, so they can go straight there in the code to make the change. If symbols are already configured, SUA will pick them up. For non-developers, this is less interesting.

    Stack traces are how you spot all of the functions that are currently being called by the application. This, in combination with symbols, tells you not only where you are in the code, but how you got there. Perhaps there is only a LUA Bug when you call a certain function from one place, but not from others – the stack trace can help you find that.

    As for what is new in SUA, I list some of the features in my post here:



  11. Jesse Proulx says:

    Does the virtualization done by UAC behave diffrently in a domain envirement? Its always seems like we have compatibility issues that force us to have users run applications as local admins when the same software run perfectly on my computer that isnt in the domain as a standard user. I have managed to run SUA on my computer to make custom sdb’s that would fix these problems sometimes. however more often than not it seems that the UAC is just not virtualizing right in a domain envirement.

  12. cjacks says:

    Jesse Proulx – virt is identical, domain or no. It’s just a file system filter driver. I’d make sure you don’t have virt turned off as part of group policy on the domain. You talk about SUA and SDBs which is separate from virtualization. However, shims also work the same, assuming you haven’t turned off the shim engine via group policy on the domain.

Skip to main content