Take the 2-minute tour ×



  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?

share|improve this question
Btw, after answering I realized I wasn't clear about something - is this referring to Local Administrator, or e.g. Domain Admins? –  AviD Feb 1 '11 at 15:40
@AviD - I'm trying to keep this to TOCTTOU in general, but the particular case I'm dealing with is local Administrator. –  Iszi Feb 1 '11 at 15:50
@Iszi I think you're having issue with the given answers, because you're actually asking two different questions. 1. How does one deal with TOC-TOU issues, in general? 2. How can you prevent a temporary administrator (on Windows) from secretly becoming one permanently? And maybe even a third: 3. How does one fix vulnerabilities in Windows :).... Perhaps if you separate the questions, you'll get better answers (better being more helpful to you). –  AviD Feb 1 '11 at 21:43
@AviD - The question posed is exactly what is written in the title. It's not at all meant to address software bugs - that's Microsoft's job of course. The issue of Administrator rights was only meant to be given as an example, although it does happen to be one which I currently face. –  Iszi Feb 2 '11 at 1:14
Then can I suggest, changing the body of the question? The example you gave is not a problem of TOC-TOU. And, in general, that is not a "vulnerability", it is the way Windows security tokens are designed. There was never any intention of immediate privilege removal, especially not in the case of administrators... (yes yes, it's feature, not a bug ;) ) –  AviD Feb 2 '11 at 9:20

3 Answers 3

up vote 4 down vote accepted

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.
share|improve this answer
Cisco devices do this too, combined with the granularity of ACS it works great. You can also end up with delays on every command execution, trade-offs. –  Scott Pack Feb 1 '11 at 20:01
Great example of what needs to be done, but the question is how to do it? –  Iszi Feb 1 '11 at 20:23
@Iszi I think step 1 is to get a job at Microsoft, in this case. –  user185 Feb 3 '11 at 11:34
Yeah, but I'm more looking for solutions that don't require step 1. That is, if such a thing exists. –  Iszi Feb 3 '11 at 19:01
Can't be done, AFAICT. You could force-logout the user. Nasty, but effective. –  user185 Feb 3 '11 at 19:38

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.

share|improve this answer
This is why I specified "aside from not granting the user rights". I'm fully aware of the risks involved with granting end-users Administrator rights, but I'm sure that TOCTTOU is an issue applicable to more than just that. –  Iszi Feb 1 '11 at 16:08
@Iszi - what I'm trying to say here is that this is more than just TOC-TOU - that is only one (small) part of the problem. I agree that TOC-TOU is wider than just this problem... –  AviD Feb 1 '11 at 16:13

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.

share|improve this answer

Your Answer


