Happy 2014 to you all (and some Gradle and SecuRT to go)

Happy new year to whomever is reading this. May it bring you security and happiness.

Today I pushed my first version onto git after playing with Gradle as my new building environment. The reason that I moved is that I like to have an environment to develop in which is flexible (like ant), but also has build in dependency management (like Maven) all into one (unlike ant combined Ivy). The fact that Maven is not really flexible to the extend that you can’t do stuff like the following:

// after first compilation, build the basic bootstrap classes
task compileJava.doLast {
    javaexec {
        classpath sourceSets.main.runtimeClasspath
        main = generator
        args = [

There are still some issues with Gradle that can be done more neatly or nicely, but for now it compiles, builds and tests the classes that I want. (if you can send me improvement, please do).

Currently I’m working in getting java.sql.Statement checked. As this is an interface you can’t just alter it, but that has to be done in runtime. I have to find a way in finding the correct class and altering that. I know it can be done through a JavaAgent, but for now I don’t want to add more ‘JVM Arguments’ to the command line. I like to keep it ‘simple’ for the intended end user.

So far, look at github and tell me what you think.,

Next Steps

I’m not the most regular poster, but Dinis Cruz encouraged me to use it more for mental notes to myself (can’t find the exact blog posting, but will give the link when I remember it). So that’s what I’m going to do from now on.

At the moment I’m ‘automating’ my Evil bit system. I’ve created an XML file which will be used to generate the altered classes. It’s easier to use the following contrust:

        <!--source class="java.lang.StringBuilder" method="toString"/ -->
        <source class="java.io.BufferedReader" method="readLine" arguments="boolean" />
        <source class="java.io.RandomAccessFile">
            <method name="readUTF"/>
            <method name="readLine"/>
        <sink class="java.io.PrintStream" method="print" arguments="java.lang.String" vulnerable="1"/>
        <sink class="java.io.DataOutput">
            <method name="write" arguments="int" vulnerable="1"/>

I’ve also decided to use a static class for the tainting and testing, this will allow for simple adjustments in the future, but as I have to use the altered String class it did give me some challenges in defining the whole build process.

    private static void createTaintUtil(String destPath) throws NotFoundException, CannotCompileException, IOException {

        ClassPool cp = ClassPool.getDefault();

        // Just a shortcut to copy the Superclass to the new destination
        CtClass atu = cp.get("org.owasp.securt.AbstractTaintUtil");

        CtClass cc = cp.makeClass("org.owasp.securt.TaintUtil", atu);

        cc.addMethod(CtNewMethod.make("public static void setTaint(String tainted, boolean taint) {if(tainted != null){tainted.setTaint(taint);}}", cc));
        cc.addMethod(CtNewMethod.make("public static void checkTaint(String tainted) {if(tainted.isTainted())markTaint();}", cc));


So what are my next steps? My ideas for going forward are as follows:
– taint the java.sql.Statement Interface (or at least have the implementation of the interface tainted from the bootclasspath)
– have a PoC for tainting J2EE classes
– perhaps have more fine grained tests of taints like Gravizapa (don’t know yet if I should pursue that or not)

That’s it for now. Happy holidays and a merry new year to whomever reads this 😉

Migration to an easier environment

In my previous post I mentioned that I got the Evil bit set. But I had to do that the long way round, as in, I actually changed the code in the OpenJDK of the following classes:

  • java.lang.String
  • java.lang.AbstractStringBuilder
  • java.lang.StringBuilder
  • java.io.BufferedReader
  • java.io.PrintStream

My PoC worked, but for every change I build into it, I had to wait for about 20 to 25 minutes on the compilation step. Which, of-course, for me is unacceptable but it did show that my initial feeling around the tainted String was correct. So now I made a newer version in which I use Javassist to build the modified classes based on the used JDK.

        ClassPool cp = ClassPool.getDefault();
        CtClass cc = cp.get("java.lang.String");

        // add the new tainted field
        CtField f = new CtField(CtClass.booleanType, "tainted", cc);

        // generate getters and setters for the new field
        cc.addMethod(CtNewMethod.getter("isTainted", f));
        cc.addMethod(CtNewMethod.setter("setTaint", f));

This removes the dependency to my build version, but allows anybody to create their own SecureRT.jar file (ok, modified classes for now) and test their applications on the potential use of tainted strings.