# Friday, September 12, 2008
Critical .NET Security Vulnerability

While browsing the Rotor sources yesterday, I noticed something that looked like a potential security issue. After writing some test code I confirmed that it was indeed a problem. Like last time, it's a bug that allows you to compromise type safety.

Previously I promised to write more about the issue after the fix was released, but I never got around to it, partly because security issues aren't very exciting anymore after they've been fixed.

BTW, my "no Microsoft bug filing policy" doesn't apply to security issues, so I've notified the Microsoft Security Response Center of the issue.

Anyway, I thought this would be a good opportunity to look at the previously fixed issue and demonstrate how a type safety hole leads to arbitrary code execution and makes it trivial to bypass both DEP and ASLR.

Discovering the Bug

This is the hard part. Contrary to popular belief, Microsoft writes pretty secure code nowadays. I found the issue because an IKVM user reported a problem with some code that worked with JIT optimizations disabled, but mysteriously failed when JIT optimizations were on. Debugging this issue led to misbehaving code similar to this:

    if (arr1[index * 3 + 5] != null)
      Union1 u1 = arr1[index * 3 + 5];

Due to a JIT bug the second array indexing expression was incorrectly applied, resulting in the ability to read a value outside of the array bounds.

Type Safety

Due to the predictability of memory allocation in managed code, it is easy to allocate two arrays of different types and then use the above bug to access an element from one array through a reference to the other array. This gives you the ability to perform a cast that otherwise wouldn't be allowed.

Once you have this ability, it can be easily abused. For example, you could create a class like this:

class StringHack
    public int arrayLength;
    public int stringLength;
    public char ch1;
    public char ch2;

If you now obtain a reference typed as StringHack to a real string object, you have the ability to alter the contents of the string (well, the first two characters in this example).

However, it's not just the .NET access restrictions that can be bypassed, you can also use this trick to execute arbitrary machine code.

Next time we'll look at a PoC that, given a type safety hole, will allow you to call WinExec to start any application from partially trusted .NET code.

Friday, September 12, 2008 9:41:53 AM (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]
# Monday, September 1, 2008
New Development Snapshot

Lots of cleanup and restructuring. Removed most .NET reflection (almost everything is now based on DynamicMethod) and improved support for running in partial trust.

Changes since previous development snapshot:

  • Switched almost all code to using generic collections.
  • Removed our own tracking of LocalBuilders, because on .NET 2.0 LocalBuilder has a LocalIndex property.
  • Added multi target support to ikvmc (although it is currently disabled, because of a showstopper .NET Ref.Emit bug).
  • Replaced usage of BootstrapClassLoader with actual class loader in static compiler.
  • Moved generated exception mapping code from ExceptionHelper to Throwable and made it slightly less hacky.
  • Replaced mapxml Hashtable with three statically typed Dictionaries.
  • Eleminated some (CompilerClassLoader) downcasts by making the type of the DynamicTypeWrapper.classLoader field depend on whether we're compiling the runtime or ikvmc.
  • Removed unused per-type class caching.
  • Added helper methods to no longer require reflection to instantiate DirectByteBuffer from JNI.
  • Bug fix: dynamic (for unloadable classes) getfield/getstatic/invoke* bytecode compilation couldn't handle ghost types.
  • Changed dynamic (for unloadable classes) bytecode handling to use Java reflection.
  • Changed JNI reflection to be based on Java reflection (where possible).
  • Removed "slow" reflection.
  • Removed MethodWrapper.Invoke().
  • Removed FieldWrapper.GetValue()/SetValue().
  • Added ICustomInvoke for the few MethodWrappers that still require custom reflection invocation.
  • Removed class init workaround that is no longer required since .NET 2.0 SP1.
  • Removed GNU Classpath specific code that I missed.
  • Switched from obsolete ConfigurationSettings.AppSettings to new ConfigurationManager.AppSettings.
  • Fixed VFS root directory entry.
  • Removed no longer needed VM.isBooted() check (VM.isBooted() always returns true now on IKVM).
  • Forked java/nio/Bits.java to remove unsafe code from static initializer.
  • Moved all creations of DynamicMethod to util method that uniformly handles the fallback to the new .NET 2.0 SP1 constructor that support partial trust.


Development snapshots are intended for evaluating and keeping track of where the project is going, not for production usage. The binaries have not been extensively tested and are not strong named.

This version supports .NET 2.0 SP1 and Mono 2.0.

Binaries available here: ikvmbin-0.37.3166.zip

Monday, September 1, 2008 9:04:03 AM (W. Europe Daylight Time, UTC+02:00)  #    Comments [4]
# Wednesday, August 27, 2008
Cecil Conclusion

I finished the Cecil.Reflection.Emit prototype of ikvmc. As I, unfortunately, expected the performance isn't acceptable. Compiling tools.jar takes approx. 18 seconds with the Ref.Emit backend, but takes 51 seconds with the Cecil based backend.

Now, I'm not knocking Mono.Cecil because of its performance, because I think the design was based on making it easy to load an assembly, tweak it and write it back out again. For that application the design makes a lot of sense, but it is less efficient for a write only task.

However, I did have to conclude that Mono.Cecil is not mature enough for usage with ikvmc. I had to write my own custom attribute encoder to work around Mono.Cecil's brokenness and I found that it doesn't properly support custom modifiers.

What Next

Given that neither Ref.Emit nor Cecil look like viable short term strategies for multi target support in ikvmc, I think it makes sense to start working on the 0.38 release now and put off the splitting of IKVM.OpenJDK.ClassLibrary.dll until the next release. I know this will disappoint some people, especially since it grew by about 4.7MB again (mostly due to the inclusion of the charsets.jar character encodings).

I don't have a timetable, but don't expect the release tomorrow. It'll be a while. First OpenJDK6 b12 needs to be released (and integrated) and then a whole lot of testing needs to be done.

Wednesday, August 27, 2008 6:11:46 AM (W. Europe Daylight Time, UTC+02:00)  #    Comments [3]
# Tuesday, August 12, 2008
Using Mono.Cecil instead of Reflection.Emit in IKVMC

I prototyped a Reflection.Emit layer for Mono.Cecil and integrated it with ikvmc. Preliminary results:

  • It looks like it is feasible to replace "using System.Reflection.Emit;" with "using Cecil.Reflection.Emit;" and only require a handful of "#if CECIL"s sprinkled through the code.
  • Mono.Cecil is lacking some functionality required by ikvmc (global methods, multi module assemblies, support for calli signatures [AFAICT], support for byte[] arguments in custom attributes)
  • Given the architecture of Mono.Cecil I'm worried that it will perform worse than Reflection.Emit (which, on .NET, is already pretty slow).

I'm pretty sure there are more issues waiting to be discovered, but these I found while trying to compile a relatively simple .class file. I got it to generate a verifiable assembly using the following ikvmc command:

        ikvmc test.class -target:library -nostacktraceinfo

If you want to play along, the Cecil.Reflection.Emit layer plus the ikvmc patch (relative to current cvs) can be found here.

At this point I'm not sure what's next. I don't feel working on Mono.Cecil is the best use of my time. I may have to put the multi assembly feature of ikvmc on the back burner (which also means no progress in splitting up IKVM.OpenJDK.ClassLibrary.dll).

On a more possitive note, doing this work made me realize that ConstructorBuilder is a useless annoyance and I can simplify some ikvm code by only using MethodBuilder (it turns out that DefineMethod can also be used to define a constructor).

Well, I will be able to do this once Mono's DefineMethod is fixed so that it notices that a constructor is created and not insert another default constructor.

Update: Zoltan already fixed the Mono bug. Thanks!

Update 2: Jb Evain pointed out that global methods are supported (simply add the methods to the <Module> type) and that calli is supported via Mono.Cecil.CallSite.

Tuesday, August 12, 2008 5:39:21 PM (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]
# Sunday, August 10, 2008
Reflection.Emit Bug

I started working on support for compiling multiple assemblies at once with ikvmc (to support mutual depedencies) and ran into a rather annoying bug:

using System;
using System.Reflection;
using System.Reflection.Emit;

class Program
  static void Main()
    AssemblyBuilder ab1 = AppDomain.CurrentDomain.DefineDynamicAssembly(new AssemblyName("A1"), AssemblyBuilderAccess.Save);
    AssemblyBuilder ab2 = AppDomain.CurrentDomain.DefineDynamicAssembly(new AssemblyName("A2"), AssemblyBuilderAccess.Save);
    ModuleBuilder mod1 = ab1.DefineDynamicModule("A1");
    ModuleBuilder mod2 = ab2.DefineDynamicModule("A2");

    TypeBuilder tb1 = mod1.DefineType("T1");
    TypeBuilder tb2 = mod2.DefineType("T2");

    ConstructorBuilder cb1 = tb1.DefineConstructor(MethodAttributes.Public, CallingConventions.Standard, null);
    ConstructorBuilder cb2 = tb2.DefineConstructor(MethodAttributes.Public, CallingConventions.Standard, new Type[] { tb1 });

    ILGenerator ilgen = cb1.GetILGenerator();

    ilgen.Emit(OpCodes.Newobj, cb2);

Running this on .NET 2.0 SP1 results in:

Unhandled Exception: System.Runtime.InteropServices.COMException (0x80131130): Record not found on lookup. (Exception from HRESULT: 0x80131130)
   at System.Reflection.Module._InternalGetMemberRef(Module refedModule, Int32 tr, Int32 defToken)
   at System.Reflection.Emit.ModuleBuilder.InternalGetConstructorToken(ConstructorInfo con, Boolean usingRef)
   at System.Reflection.Emit.ILGenerator.GetMethodToken(MethodBase method, Type[] optionalParameterTypes)
   at System.Reflection.Emit.ILGenerator.Emit(OpCode opcode, ConstructorInfo con)
   at Program.Main() in c:\vsp\RefEmitBugRepro\Program.cs:line 23

The "no Microsoft bug filing" policy is still in effect, so I won't be filing a bug with Microsoft for this.


For the scenario above there is a (painful) workaround. You can create your own ConstructorInfo subclass that represents the constructor you want to call, if you do that ILGenerator.Emit() will end up in a different code path to lookup the token and that code path does work.

I haven't tried it, but I assume this workaround also works for methods and fields.

I think that for ikvmc I won't be using this workaround, but instead I'll treat this as a good reason to finally start looking into using Mono.Cecil instead of Reflection.Emit.

Sunday, August 10, 2008 10:02:40 AM (W. Europe Daylight Time, UTC+02:00)  #    Comments [3]
# Thursday, August 7, 2008
New Development Snapshot

Time for another snapshot.

Changes since previous development snapshot:

  • Removed support for building with GNU Classpath class library.
  • DatagramSocket: Implemented connected datagram sockets using .NET 2.0 API.
  • DatagramSocket: Used .NET 2.0 Socket.IOControl() API to disable WSAECONNRESET errors (when not connected).
  • DatagramSocket: Throw PortUnreachableException from receive() if we receive WSAECONNRESET while connected.
  • Various java.util.zip compatibility and bug fixes.
  • Fixed bytecode compiler not to generate unneeded GC.KeepAlive() in constructor for Exception types that don't have a finalize() method.
  • Fixed #2001802 contributed by Andy Malakov.
  • Fixed #2001799.
  • Fixed #2006953.
  • Fixed file I/O error handling incompatibilities.
  • Added ghost array tagging to be able to report the instantiated class (instead of the object[] which is allocated instead).
  • Fixed ldc <class> where <class> is a ghost array.
  • Fixed bug in instanceof <class> where <class> is a Serializable[].
  • Removed Mono workarounds that are no longer needed with Mono 2.0.


Development snapshots are intended for evaluating and keeping track of where the project is going, not for production usage. The binaries have not been extensively tested and are not strong named.

This version supports .NET 2.0 SP1 and Mono 2.0.

Binaries available here: ikvmbin-0.37.3141.zip

Thursday, August 7, 2008 8:13:00 AM (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]
# Wednesday, July 9, 2008

I'll be at the PDC again this year. Drop me a line if you're going and want to meet me there to chat (or to buy me a beer ;-)).

Meet me in Los Angeles -- PDC 2008

Wednesday, July 9, 2008 7:35:32 AM (W. Europe Daylight Time, UTC+02:00)  #    Comments [1]
# Monday, June 30, 2008
Exception Performance Part 2

Last time we saw that CLR exception handling is significantly slower than HotSpot exception handling. This time we'll look at two very variations of the ExceptionPerf1 microbenchmark that significantly affect performance.

I've highlighted the changes.

Variation 1

public class ExceptionPerf2 {
  public static void main(String[] args) {
    long start = System.currentTimeMillis();
    for (int i = 0; i < 100000; i++) {
      try {
      catch (NumberFormatException x) {
    long end = System.currentTimeMillis();
    System.out.println(end - start);

Variation 2

public class ExceptionPerf3 {
  static NumberFormatException exc;
  public static void main(String[] args) {
    long start = System.currentTimeMillis();
    for (int i = 0; i < 100000; i++) {
      try {
      catch (NumberFormatException x) {
        exc = x;
    long end = System.currentTimeMillis();
    System.out.println(end - start);


      HotSpot 1.6 x86     .NET 1.1 SP1     .NET 2.0 SP1 x86     Mono 1.9 x86
ExceptionPerf1 111 14743 3590 537
ExceptionPerf2 140 15735 10761 36309
ExceptionPerf3 112 14946 9728 24107

.NET/Mono results with IKVM 0.36

Why do these small changes have such a big perf impact?

Both these changes result in additional stack trace data being collected. IKVM has some optimizations that prevent gathering stack traces in very specific circumstances. Normally when you create a Java exception object, the Throwable constructor will call Throwable.fillInStackTrace(). However, since this is a very expensive operation, IKVM tries to remove this call when it is unnecessary (i.e. when it sees that you immediately throw the exception and the exception type doesn't override Throwable.fillInStackTrace()). Additionally, in Java an exception object will always have the complete stack trace, but a .NET exception only has the stack frames from the throw to the catch site. This means that at the catch site IKVM will collect the rest of the stack trace, unless the exception object isn't used (as in the ExceptionPerf1 microbenchmark).

The time it takes to collect a stack traces obviously depends on the call stack depth, so let's look at a microbenchmark to measure that effect:

class ExceptionPerf4 {
  public static void main(String[] args) {

  static void nest(int depth) {
    if (depth > 0) {
      nest(depth - 1);
    } else {

  static void run() {
    Exception x = new Exception();
    long start = System.currentTimeMillis();
    for (int i = 0; i < 100000; i++) {
    long end = System.currentTimeMillis();
    System.out.println(end - start);


Depth     HotSpot 1.6 x86     .NET 1.1 SP1     .NET 2.0 SP1 x86     Mono 1.9 x86
1 64 2930 4611 19377
10 85 3814 6787 34895
100 380 12500 27935  
1000 3543      

For the curious, the IKVM implementation of Throwable.fillInStackTrace() is essentially new System.Diagnostics.StackTrace(true);

Next time we'll wrap things up.

Monday, June 30, 2008 9:22:06 AM (W. Europe Daylight Time, UTC+02:00)  #    Comments [1]
# Wednesday, June 25, 2008
Exception Performance Part 1

One area where IKVM performance is much worse than HotSpot is in throwing and catching exceptions. This blog is the first of three that will look into why this is the case.

We start out with two microbenchmarks to highlight the differences.


public class ExceptionPerf1 {
  public static void main(String[] args) {
    long start = System.currentTimeMillis();
    for (int i = 0; i < 100000; i++) {
      try {
      catch (NumberFormatException x) {
    long end = System.currentTimeMillis();
    System.out.println(end - start);


using System;

class ExceptionPerf1 {
  public static void Main(string[] args) {
    int start = Environment.TickCount;
    for (int i = 0; i < 100000; i++) {
      try {
        throw new Exception();
      catch (Exception) {
    int end = Environment.TickCount;
    Console.WriteLine(end - start);


      HotSpot 1.6 x86     .NET 1.1 SP1     .NET 2.0 SP1 x86     Mono 1.9 x86
Java* 111 14743 3590 537
C#   11139 2605 187

*.NET/Mono results with IKVM 0.36

This shows that the situation on the CLR is pretty bad. If you care about exception throwing performance, please complain to Microsoft instead of to me. Although I expect that they'll tell you not to throw so many exceptions. ;-)

On the next episode we'll see that the above microbenchmark is actually a best case scenario for IKVM and we'll see how things can get much worse...

Wednesday, June 25, 2008 12:40:19 PM (W. Europe Daylight Time, UTC+02:00)  #    Comments [3]
Useful Tool

Andy Malakov wrote an Ant task for ikvmc. It also contains a doclet that can generate an xml mapping file that contains all the parameter names that ikvmc can then attach to the .NET methods (ikvmc already does this for methods with debugging information, but that doesn't work for abstract methods).

Good stuff!

Wednesday, June 25, 2008 9:08:54 AM (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]