# Monday, 25 June 2012
« MS12-038 and IKDASM | Main | Experimental WinRT Support in IKVM.Refle... »
Why ASP.NET Medium Trust Isn't

On October 24 of last year I reported an ASP.NET Medium Trust vulnerability. This eventually resulted in KB 2698981 where Microsoft essentially deprecated ASP.NET Partial Trust.

The problem I reported was that it is possible to abuse Thread.Abort() to create an inconsistent TypedReference that violates type safety.

TypedReference is an interesting type and I've been on the lookout for a way to abuse it for a long time. It's purpose is to allow type safe references to be used in a generic way. To implement this a TypedReference contains both a pointer and a type and all operations it allows make sure that type safety isn't violated. It's a primitive type, so the runtime knows about it and treats it specially. It can be used from partially trusted code and because it can contain a reference to a location on the stack, the runtime enforces that TypedReference values can only be used from a single thread (by disallowing boxing or storing it in arrays or fields).

However, by having one thread repeatedly overwriting a TypedReference location on the stack with two different values and a second thread aborting the first thread at the right moment, you can end up with a TypedReference that combines the pointer from one value and the type from another value and thus violating type safety.

The source of the PoC is available here.

Monday, 25 June 2012 10:26:33 (W. Europe Daylight Time, UTC+02:00)  #    Comments [3]
Tuesday, 26 June 2012 14:31:19 (W. Europe Daylight Time, UTC+02:00)
The second I read "Thread.Abort" and "TypedReference" I knew immediately what you were up to ;-)

That trick must work for other types as well, right? Thinking of ArgIterator right now.

Anyway, why is this a medium-trust vulnerability? It gives any code control over the process, right?
tobi
Tuesday, 26 June 2012 14:39:02 (W. Europe Daylight Time, UTC+02:00)
Yes, ArgIterator has the same problem, but it is not as convenient to exploit ;-)

It requires medium trust because Thread.Abort() isn't allowed in lower trust levels. Although it might be possible to abuse a thread abort done by the runtime.
Tuesday, 26 June 2012 16:48:34 (W. Europe Daylight Time, UTC+02:00)
ASP.NET will abort on a timeout. You can also abuse System.Media.SoundPlayer: It starts a loader thread and aborts it on a timeout. The horribleness of this design aside, you can execute code on the loader thread by creating a custom URI prefix or by registering a custom synchronizationcontext.

I guess we can all learn from the .NET security model that same-process isolation doesn't really work in a complex system. Too many entry points and API surface.
tobi
Name
E-mail
Home page

I apologize for the lameness of this, but the comment spam was driving me nuts. In order to be able to post a comment, you need to answer a simple question. Hopefully this question is easy enough not to annoy serious commenters, but hard enough to keep the spammers away.

Anti-Spam Question: What method on java.lang.System returns an object's original hashcode (i.e. the one that would be returned by java.lang.Object.hashCode() if it wasn't overridden)? (case is significant)

Answer:  
Comment (HTML not allowed)  

Live Comment Preview