Welcome to MSDN Blogs Sign in | Join | Help

Impersonation and Exception Filters in v2.0

A while back, I wrote about a potential security hole when malicious code can set up an exception filter before calling your code which does impersonation.

In the final release of v2.0, we've added a feature to help mitigate this problem.  The CLR records that you've begun impersonation on the stack frame where you make the call to Impersonate().  If an exception is thrown, when the CLR walks the call stack looking for handlers, it will see this note and revert the impersonation when it moves past the frame.

This means that the following sample from my previous post would just work under v2.0:

public void SomeApi()
{
    // Call LogonUser to get a token for the user
    IntPtr userHandle = IntPtr.Zero();
    bool loggedOn = LogonUser(
        user,
        domain,
        password,
        LogonType.Interactive,
        LogonProvider.Default,
        out userHandle);
    if(!loggedOn)
        throw new Win32Exception(Marshal.GetLastWin32Error());

    // Begin impersonating the user
    WindowsImpersonationContext impersonationContext = null;
    try
    {
        WindowsIdentity.Impersonate(userHandle.Token);
        DoSomeWorkWhileImpersonating();
    }
    finally
    {
        // Clean up
        CloseHandle(userHandle);
        if(impersonationContext != null)
            impersonationContext.Undo();
    }
}

When the call to Impersonate() is made, the CLR notes that on SomeApi()'s stack frame and if DoSomeWorkWhileImpersonating() happens to throw, the impersonation is reverted before any callers of the SomeApi() have their exception filters run.

Note that since this state is tied to the stack frame, you won't get this benefit if you impersonate in one method and revert in another:

public void SomeOtherApi()
{

    // Begin impersonating the user
    WindowsImpersonationContext impersonationContext = null;
    try
    {
        impersonationContext = BeginImpersonating();
        DoSomeWorkWhileImpersonating();
    }
    finally
    {
        // Clean up
        if(impersonationContext != null)
            impersonationContext.Undo();
    }
}

Here, the impersonation is done in the BeginImpersonating() method, but is reverted in SomeOtherApi().  In this case, the stack frame for BeginImpersonating() is gone if DoSomeWorkWhileImpersonating() throws an exception.  Since the BeginImpersonating() stack frame is the one which contained the annotation that impersonation needed to be undone, you lose the automatic revert behavior.

Obviously getting the undo for free is a much better option than having to go through all the work of protecting your code manually, so as you begin upgrading your code to run with v2.0 of the framework, you might want to look for places where you don't both impersonate and undo the impersonation in the same method.

Published Friday, March 03, 2006 7:00 AM by shawnfa
Filed under: ,

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# re: Impersonation and Exception Filters in v2.0

Friday, March 03, 2006 12:59 PM by dominick
Hi Shawn, excellent! good work! now i have to change my slides again :))

# Impersonation and Exception Filters in v2.0

Friday, March 03, 2006 10:09 PM by dotnetkicks.com
Trackback from dotnetkicks.com

# re: Impersonation and Exception Filters in v2.0

Monday, March 06, 2006 1:04 PM by Marc Brooks
Is this cool behavior extensible? Is there an attribute we can decorate things with that will cause thier Dispose to get called just like this (clever, cool) hack?

# MSDN Flash Ireland Resources - 31 Mar 06

Friday, March 31, 2006 12:17 PM by Robert Burke's Weblog
Web Resources





[.NET Framework] GotDotNet CodeGallery
Share, find, download and discuss evolving...

# .NET Resources

Saturday, May 06, 2006 4:29 AM by mattonsoftware.com
The following links to .NET resources have been collated over time with the assistance of colleagues. ...

# So, What Was Wrong with That Code Anyway?

Wednesday, December 06, 2006 10:07 PM by K. Scott Allen

WWWTC #9 ranks 10 out of 10 on the "difficult and subtle" scale. Let's say we write the following...

# So, What Was Wrong with That Code Anyway?

Wednesday, December 06, 2006 11:10 PM by Mirror blog entries from the industry

WWWTC #9 ranks 10 out of 10 on the "difficult and subtle" scale. Let's say we write the following code

# C# and VB.NET Security Throwdown!

Tuesday, February 24, 2009 12:23 PM by KeepItLocked.net

.NET doesn't care what language you write in - as long as your code compiles to MSIL, it's a .NET application

Leave a Comment

(required) 
required 
(required) 

  
Enter Code Here: Required
 
Page view tracker