How can TOCTTOU vulnerabilities within the Windows OS be mitigated?

Question

What are some ways to mitigate the time-of-check-to-time-of-use issues that apply to Windows permissions?

Example:

1. End-user is added to the local Administrators group in order to install software, printers, etc.
2. The user's account is removed from the Administrators group while the user is logged in.
   
   • The change in permissions will not apply until the user's next login.
3. The user, with Administrator rights still applied, adds themselves back to the Administrators group before logging off - reversing the removal.
4. The next time the user logs in, they still have Administrator permissions until they are (and stay) removed again.

Aside from just not granting Administrator rights to end-users in the first place (obvious solution), or by any other means that require specific end-user actions, what are some ways the above scenario (or similar Windows-inherent TOCTTOU issues) can be prevented?

Answer 1

Without actually answering the declared question, I want to address your given example - because I think you're actually just trying to solve that issue, and not the generic issue.

Once you grant administrative privileges to a user - it's done with, you aint never getting them away again.
As you say, the user can just add himself back into the Administrators group... But there are actually many, many other ways he can do ensure that he keeps his privileges, while he still has the privilege, such that you would be hard pressed to remove it, even if you happened to have full and complete system auditing turned on.

For example, he can create another user, and add that to Administrators.
Or reset the password on Administrator, and enable that. (Since you don't use it, right??, you'd never know...)
Or create another group, make it hidden, and add that as a member of Administrators.
Or, simply setup some Windows Service, or MSTask etc, running as LOCALSYSTEM.
Or install some kinda rootkit.

Of course the system auditing won't really help, since and Admin can easily shut that off, temporarily...

I could go on, but I hope I already proved my point... TOC-TOU is not your problem here, it's granting temporary administrative privileges (not really possible), or maybe dealing with malicious administrators (Really Hard Problem) in general.

As you said, don't grant Administrator privileges to end users. There are other solutions to enable them to install programs.

Answer 2

Fix Windows (or your own applications, where applicable - in your example you'd need to fix Windows). The TOCTOU vulnerability can only be addressed by not separating checking from use. A far more common example in applications I've seen: temporary files (yes, people still get this one wrong). Just because a file doesn't exist when you look doesn't mean it won't exist when you go to use it.

Specific to this example: Mac OS X's authorization services doesn't check what privileges you have when you log in. It finds out whether you can acquire a right at acquisition time. In a well-designed application, the privileged component examines whether you have the right upon use, so the window for a TOCTOU vulnerability is limited. It's non-zero - I could acquire a right, have that right revoked, then pass the security context I already gained to the privileged component, but there's a time limit on that.

---

So, let's say that you managed to get yourself a job at Microsoft, and you were tasked with fixing this bug. You find (I'm making up the API for purposes of argument, but this is how it would work) that when a user logs in, the session manager does securityContext = GetUserAccountControlsContext(); which copies the user's rights from the central database or directory service so the session can refer to it.

Later, you find that the code for managing user rights calls IsUserAuthorizedForAction(kMakeUserAdminAction, securityContext); to discover whether the UI for making himself admin should be enabled. When he clicks the button, MakeUserAdmin(user) also calls the same check, with the same security context.

The fix is to remove the initial acquisition of the context. Change the tests for IsUserAuthorizedForAction(action, context) to call GetUserAccountControlsContext() themselves. The result should not be cached, but should be looked up afresh at each call. This leaves two outstanding problems:

1. When the UI-enabling check is done, the user is not authorized, but becomes so at some later time. You can fix this by observing for changes to the security context, or accept it as a slight annoyance that will infrequently occur.
2. When the UI-enabling check is done, the user is authorized, but by the time he clicks the button he is not authorized. This is handled by the fact that MakeUserAdmin() tests the (up-to-date) security context. It should throw an exception if it can't actually get sufficient privileges to do what it needs.

Answer 3

This is one of those situation where the method is inherently insecure, since it does not follow a least privileges model.

As far as Windows is concern, there are far better ways of allowing a user to install an application. Under Server 2003 and Windows XP, you can use the Group Policy Software Install policy, which allows a user to install software off a whitelist.