raises it’s ugly head

I’ve ran into another small set back. This time it’s called the

Compare the following results:

java -DTAINT_LOGGING=true -DTHROW_EXCEPTION=true -Xbootclasspath/p:build/distributions/SecuRT-1.0-shadow.jar -Dfile.encoding=UTF-8 -ea -cp ~/.gradle/caches/1.10/workerMain/gradle-worker.jar org.owasp.securt.StandaloneTest

Error occurred during initialization of VM
java.lang.InternalError: Could not create SecurityManager:
at sun.misc.Launcher.(
at sun.misc.Launcher.(
at java.lang.ClassLoader.initSystemClassLoader(
at java.lang.ClassLoader.getSystemClassLoader(

and (what I want to happen):

java -DTAINT_LOGGING=true -DTHROW_EXCEPTION=true -Xbootclasspath/p:build/distributions/SecuRT-1.0-shadow.jar -Dfile.encoding=UTF-8 -ea -cp ~/.gradle/caches/1.10/workerMain/gradle-worker.jar org.owasp.securt.StandaloneTest

Exception in thread "main" org.owasp.securt.TaintException: Taint detected
at org.owasp.securt.AbstractTaintUtil.markTaint(
at org.owasp.securt.TaintUtil.checkTaint(
at org.owasp.securt.StandaloneTest.main(

Unfortunately the firsts result happens when you try to run your tests from Gradle. In other words, I have to investigate the relationship between the security.manager and the bootstrapclassloader. Maybe tomorrow will shed some light on a solution.
By the looks of it, I’m not the only one with this problem.

After the silence

I’ve been silent a long time. I know. I’m sorry.
I’ve been very busy with my ordinary work, family and OWASP, so this project had to take a back seat. But that didn’t meant that it was completely forgotten.

As I’ve spoken in my previous post I’m dabbling with Gradle as a built environment, which is quite a relief compared to ant or Maven (although I have  to admit that I’m reverting back to ant and Ivy as soon as stuff goes a bit wonky). Next to Gradle I’ve started with Scala as well. Which is in some perspective even a nicer language than Java itself (although Java still is my default to-go-to language).

Between my last post and this one I’ve also been trying to check any class that implements the java.sql.Statement interface. as in, I want to identify a taint trace in the next bit of code:

	public void testSQL() {
		String sql = "SELECT * FROM contacts WHERE name='"+getUserName()+"'";

		Connection connection;
		try {
			connection = DriverManager.getConnection("jdbc:hsqldb:mem:mymemdb", "SA", "");
			connection.createStatement().executeUpdate("create table contacts (name varchar(45),email varchar(45),phone varchar(45))");
			System.out.println("[*] Database created");
			Statement statement = null;
			ResultSet resultSet = null;

			statement = connection.createStatement();
			// it should fail here 
			resultSet = statement.executeQuery(sql);

			fail("Should not get here");
		} catch (Exception e) {
			System.err.println("Got an exception! ");

for a long time I had been unsuccessful, soully for the reason that I had my test setup wrong. These last months/weeks have been a learning experience about the bootstrap and the other classloaders. But most of all, I’ve learned that if you define your execution path wrong (as in, having the database jar in the bootclasspath instead of the classpath) it goes wrong.

I only discovered that by reverting back to ant and Ivy and tracking it in more detail.

Next I will clean up my code and recreate it using Gradle and also start testing with other languages. Still have to decide which language I’ll focus on next.
Perhaps I’ve played with Scala long enough to choose it as the next target.

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="" method="readLine" arguments="boolean" />
        <source class="">
            <method name="readUTF"/>
            <method name="readLine"/>
        <sink class="" method="print" arguments="java.lang.String" vulnerable="1"/>
        <sink class="">
            <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

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.

The EVIL bit has been set

Today I finally managed to create a PoC in which an exception is thrown based on the presence of the evil bit. I used to PoC as described in my previous post and got it working.

Exception in thread "main" java.lang.RuntimeException: Tainted
	at SimpleTest.main(

So, what did I do.
So far, all my attempts were unsuccessful as other exceptions kept popping up (as in, not the desired one) so I went to the core of Java. I modified the OpenJDK code and added the ‘evil’ bit to the String class (with getters and setters of course):

transient boolean tainted = false; //RFC3514 compliant

To be able to acknowledge that you can’t trust the information that was read from, I modified BufferedReader.readLine to be as follows:

    public String readLine() throws IOException {
        String result = readLine(false);
        if (result != null)
        return result;

To check if tainted data is written to the System.out I modified PrintStream.print(String) to the following:

    public void print(String s) {
        if(s.isTainted()) { throw new RuntimeException("Tainted");}
        if (s == null) {
            s = "null";

This will only work when you print the String as is, however, in my PoC I prepended a welcome text to the String which meant that I had to adjust StringBuilder as well to propagate the taint. First in AbstractStringBuilder

    public AbstractStringBuilder append(String str) {
        if (str == null) str = "null";
        int len = str.length();
        ensureCapacityInternal(count + len);
        str.getChars(0, len, value, count);
        count += len;
        this.tainted |= str.isTainted();
        return this;

but also in StringBuilder itself

    public String toString() {
        // Create a copy, don't share the array
        String result = new String(value, 0, count);
        return result;

These changes are then compiled and bundled into a secure rt.jar file. Using this jar file meant that I now could do a basic taint tracing. The PoC runs as previously described, but if you run it with the secure RT.jar file the exception will be raised (as shown above).

A new approach

Thanks to Arshan Dabirsiaghi who made a comment in I got a new approach to investigate. He mentioned JRebel and their process which reminded me of the Javaagent – which I had completely forgotten. JRebel uses the Instrumentation possibility to rewrite classes to be updateable, so I’m going to use the same technique to add tracking information into Strings.

I already have created an simple test case of input validation and output encoding:

package org.owasp.securert;


public class Basetest {
    public static void main(String[] args) {
        System.out.print("Enter your name: ");
        BufferedReader br = new BufferedReader(new InputStreamReader(;
        String userName = null;
        try {
            userName = br.readLine();
        } catch (IOException ioe) {
            System.out.println("IO error trying to read your name!");

        System.out.println("Thanks for the name, " + userName);

I agree, it’s not a highly sophisticated test case, but it has security vulnerabilities. If you send the following string

'\x08\x08\x08\x08\x08\x08\x08\x08\x08\x08\x08\x08\x08\x08test                           ' 
it will print Thanks test
instead of Thanks for the name, test that you would expect.

Now I’m going to see how ‘easy’ it will be to track the taint using both approaches, Bootclassloader and Javaagent.

Up the ante

My goal with the String meta-data is actually very simple. It should be designed in such a way that all developers/testers that are using the JVM can use it. Sort of copied from the ZAP policy “It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing as well as being a useful addition to an experienced pen testers toolbox.”

The end result should be easy to use and non intrusive to existing code. For this reason I’ve started to focus on the option of customisation. If I manage to adapt the Core classes of Java in such a way that I can do taint tracing, I can create a version in which security tests can be run simultaneously to unit and integration tests.

By allowing that the security testing is executed during unit and/or integration tests that would mean that ‘ordinary’ developers can perform these tests without those pesky security testers. And by changing the base classes themselves, it would mean that the test would be non intrusive to the actual code created by the developers in the first place.

The changed base classes should not be used in production systems, but if I manage with this, perhaps those production systems would be a bit more secure.

Where to start

As described in my previous post, I want to add meta-data to a String in Java. This meta-data should be used for example to mark a String as tainted (contains not validated text) from a security perspective. Unfortunately it isn’t as simple as it sounds as the Java String class has various ‘exit-points’ for it’s value, a.k.a. just marking the String class might not be enough.

We (Dinis Cruz and me) have a couple of options to investigate:
1. Customize the String class and add the taint mark to it. This means that a custom bootstrap is needed to be able to use the adapted String class.
2. Using AOP and try to make a note of the char array within the class and follow that.
3. Use JNI or JNA and mark the char array in a way.
4. Add information to the char array in memory to indicate that it contains tainted data.
There maybe other options, but we’re not aware of those (yet).

I do know that it will add tremendous value to a security test if we can demonstrate if tainted data flows through the application. This is the basis of a potential vulnerability, and if we can demonstrate this to the developers it might be mitigated before it can be abused.
Lets see if we can make this work.