SafeHandle: A Reliability Case Study [Brian Grunkemeyer]

Brian Talks About SafeHandles

Chris Lyon's WebLog — Wed, 16 Mar 2005 22:24:00 GMT

Tips

David Boschmans' Weblog — Thu, 17 Mar 2005 22:16:00 GMT

Tips

Brian Talks About SafeHandles

Chris Lyon's WebLog — Fri, 18 Mar 2005 02:50:00 GMT

Tips

Ido Samuelson — Mon, 21 Mar 2005 19:36:00 GMT

Tips

re: SafeHandle: A Reliability Case Study [Brian Grunkemeyer]

John Lyon-Smith — Tue, 22 Mar 2005 04:33:00 GMT

Great blog Brian. The best I've read on SafeHandles so far. At this point I need to put my hand up and ask an unanswered question. I presume that the safeness of SafeHandles derives from the fact that the handle in question is completely used via the SafeHandle and managed code? For example, if an unmanaged thread happens to "sneak into your process" and it gets hold of an O/S handle (which is wrapped in a SafeHandle), can it can simply call CloseHandle and corrupt data and/or launch a handle recycling attack? Unless you are hooking the O/S calls at the DLL entry points there wouldn't appear to be any way to stop that.

re: SafeHandle: A Reliability Case Study [Brian Grunkemeyer]

Brian Grunkemeyer — Tue, 22 Mar 2005 05:10:00 GMT

Thanks. Yes, your concern is correct. The safety in SafeHandle is only guaranteed if the SafeHandle controls the lifetime of the handle exclusively. We do all our work with a ref count on the handle, incrementing it when we start marshaling the handle to a P/Invoke call, and decrementing it when the P/Invoke method returns, or you call Dispose on the SafeHandle. (We also designed critical finalization for SafeHandles to guarantee they get cleaned up during an appdomain unload, even if we give up running normal finalizers because one blocked for a long time.)

There are at least two ways SafeHandle can be compromised. The first is another thread (managed or unmanaged) that starts randomly guessing handle values. If another thread either has a dangling handle to a previously closed kernel object, or decides that 0xc40 is a good random number and passes that to CloseHandle(), and you have a SafeHandle that happens to have that number in it as a handle, then the handle is closed and you're open to handle recycling attacks. So as an application writer, you do have to worry about the safety & correctness of other code in your process.

Checking the return value of CloseHandle() is a good way to help track this down, and SafeHandle's ReleaseHandle() method returns a bool for this purpose. Under a native debugger, Win32's CloseHandle will hit a breakpoint if you call CloseHandle with an invalid handle. With SafeHandle, we have an MDA that, when enabled, will fire whenever SafeHandle's ReleaseHandle method returns false. This allows us to track down failures in code that doesn't use CloseHandle, etc.

The second way to circumvent SafeHandle is by using its DangerousGetHandle method without calling DangerousAddRef & DangerousRelease. For interoperability reasons, a few Framework classes exposed the handle to the user as an acknowledgement that perhaps this type didn't represent the full set of operations you want to do on this resource. So to ensure compatibility, we had to add in a mechanism to get a handle out of the SafeHandle. In those scenarios, frankly you're on your own, and we've made those methods require UnmanagedCode permission. But it isn't ideal, of course.

If you must pull a value out of a SafeHandle for some reason (note there are a few corner cases involving marshaling of SafeHandles in structs that aren't fully supported), you should use a constrained execution region to prevent the runtime from introducing failure points in your backout code. (Search around for CER's on the web - I haven't written something on them yet.) Here's an example of what you should write:

bool mustRelease = false;
RuntimeHelpers.PrepareConstrainedRegions();
try {
sh.DangerousAddRef(ref mustRelease);
IntPtr handle = sh.DangerousGetHandle();
// Do something with the handle here
}
finally {
// You can only write "reliable" code here.
if (mustRelease)
sh.DangerousRelease();
}

The Worst of the .NET 1.x Years

K. Scott Allen — Wed, 23 Mar 2005 05:28:00 GMT

Safe Impersonation With Whidbey

.Net Security Blog — Fri, 25 Mar 2005 00:16:00 GMT

Blog link of the week 24

Daniel Moth — Mon, 20 Jun 2005 00:56:04 GMT

Blog link of the week 24

Constrained Execution Regions and other errata [Brian Grunkemeyer]

BCLTeam's WebLog — Mon, 27 Jun 2005 23:42:35 GMT

A customer recently asked a good question about some of our new reliability features in Whidbey:

There...

Unmanaged Interop chapter

`(joe (@ (version "2.0")) ,(mk-blog)) — Mon, 11 Jul 2005 08:05:03 GMT

Unmanaged Interop chapter

`(joe (@ (version "2.0")) ,(mk-blog)) — Mon, 11 Jul 2005 08:07:50 GMT

Unmanaged Interop chapter

`(joe (@ (version "2.0")) ,(mk-blog)) — Mon, 11 Jul 2005 08:09:07 GMT

Unmanaged Interop chapter

`(joe (@ (version "2.0")) ,(mk-blog)) — Mon, 11 Jul 2005 10:13:25 GMT

SafeHandle

notgartner.com: Mitch Denny's Blog — Tue, 16 Aug 2005 15:49:24 GMT

Rotor (SSCLI) 2.0 is available!

Generalities & Details: Adventures in the High-tech Underbelly — Sun, 26 Mar 2006 00:01:15 GMT

Converting System.Threading.WaitHandle.Handle to System.Threading.WaitHandle.SafeWaitHandle

I want some Moore! — Fri, 23 Jun 2006 17:49:44 GMT

How to use SafeHandle in a Resilient Library [Brian Grunkemeyer]

BCLTeam's WebLog — Fri, 23 Jun 2006 18:20:40 GMT

SafeHandle is the preferred mechanism for controlling the lifetime of an OS resource (such as a handle...

CLR Behavior on OutOfMemoryExceptions [Brian Grunkemeyer]

BCLTeam's WebLog — Tue, 17 Oct 2006 21:27:01 GMT

For out of memory exceptions, keep in mind that we can run out of memory in the native heaps in the process,

Resources for geekSpeak - Garbage Collection with Jeffrey Richter

geekSpeak — Fri, 03 Nov 2006 23:17:55 GMT

Thanks again to Jeffrey Richter who gave us great insight into the garbage collector. Here are some useful

Type-safe Managed wrappers for kernel32!GetProcAddress

Mike Stall's .NET Debugging Blog — Sat, 06 Jan 2007 08:32:00 GMT

Pinvoke is cool in managed code, but sometimes you need to get straight at kernel32!GetProcAddress. For

Advanced .NET Debugging » Blog Archive » P/Invoke Unamanged Windows API Wrapper by Mike Stall

Thu, 11 Jan 2007 19:19:07 GMT

PingBack from http://dotnetdebug.net/2007/01/07/pinvoke-unamanged-windows-api-wrapper-by-mike-stall/

P/Invoking and Finalization » Advanced .NET Debugging

P/Invoking and Finalization » Advanced .NET Debugging — Fri, 12 Jan 2007 12:05:38 GMT

PingBack from http://dotnetdebug.net/2005/08/07/pinvoking-and-finalization/

Long Paths in .NET, Part 2 of 3: Long Path Workarounds [Kim Hamilton]

BCL Team Blog — Tue, 27 Mar 2007 04:05:51 GMT

For now, our suggested workaround for users that encounter the MAX_PATH issue is to rearrange directories

Long Paths in .NET, Part 2 of 3 [Kim Hamilton][译]

Tom's Notepad — Thu, 26 Apr 2007 13:12:25 GMT

Long Paths in .NET, Part 2 of 3

El laberinto de piedra » Blog Archive » SafeHandles

El laberinto de piedra » Blog Archive » SafeHandles — Mon, 07 May 2007 10:26:03 GMT

PingBack from http://arnulfoperez.com/blog/2007/05/07/safehandles/

Hopeless performance. The ADO.NET 2.0 is slower than ADO 1.1

《Windows用户态程序高效排错》文章的发布，反馈站点 — Sun, 27 May 2007 18:23:12 GMT

1.0 Warm up. Firstly my mentor shared the following question with me: Why the image gets reversed in

Soci blog » Blog Archive » SQL Server 2008 ??jdons??gok 5. - streaming adatok kezel??se kliens oldalr??l

Thu, 13 Dec 2007 14:33:03 GMT

PingBack from http://soci.hu/blog/index.php/2007/12/13/sql-server-2008-ujdonsagok-5-streaming-adatok-kezelese-kliens-oldalrol/

BCL Team Blog SafeHandle A Reliability Case Study Brian Grunkemeyer | Cellulite Creams

Tue, 09 Jun 2009 06:11:24 GMT

PingBack from http://cellulitecreamsite.info/story.php?id=4242