Overview

If one changes security privileges, one should ensure that the change was successful.

Consequences

• Authorization: If privileges are not dropped, neither are access rights of the user. Often these rights can be prevented from being dropped.

• Authentication: If privileges are not dropped, in some cases the system may record actions as the user which is being impersonated rather than the impersonator.

Exposure period

• Implementation: Properly check all return values.

Platform

• Language: C, C++, Java, or any language which can make system calls or has its own privilege system.

• Operating platforms: UNIX, Windows NT, Windows 2000, Windows XP, or any platform which has access control or authentication.

Required resources

A process with changed privileges.

Severity

Very High

Likelihood of exploit

Medium

Avoidance and mitigation

• Implementation: In Windows make sure that the process token has the SeImpersonatePrivilege(Microsoft Server 2003).

• Implementation: Always check all of your return values.

Discussion

In Microsoft operating environments that have access control, impersonation is used so that access checks can be performed on a client identity by a server with higher privileges. By impersonating the client, the server is restricted to client-level security - although in different threads it may have much higher privileges.

Code which relies on this for security must ensure that the impersonation succeeded - i.e., that a proper privilege demotion happened.

Examples

In C/C++

bool DoSecureStuff(HANDLE hPipe){ {
   bool fDataWritten = false;
   ImpersonateNamedPipeClient(hPipe);
   HANDLE hFile = CreateFile(...);
   /../ RevertToSelf()/../
}