For those that follow this site, sorry for being absent. And now a warning for those that following this site, I will be absent again. I’m not the most reliable blogger I know but that doesn’t prevent me of posting once in a while.
So what have I been doing lately. Well I’ve created an app called IssueFinder. It technically doesn’t find issues but helps in organising them. I am planning to use this corner to post more on progress/ideas.
Although I didn’t made any updates to this website, I haven’t been sitting still. I have worked my ‘but off’ to make it work. And I did. I managed to get the taint traced from source to sink, but means of only the String class itself. But that’s not where i stopped, I demonstrated that this principle not only worked in plain Java, but also in J2EE. And to top it off, it works also with other JVM languages like Scala, Jython, Groovy. Which is an added bonus.
So, in short. I managed to implement the idea that had sprung out of another Appsec conference, but then the EU 2013. The next step will be to ‘convert’ it into an OWASP project, add a roadmap, more documentation, etc, etc. Oh, and not to forget add more functionality like:
For those that are interested, the presentation that I gave at appsec usa is here.
This whole issue with the SecurityManager is actually a non issue. As it isn’t loaded throught the bootstrapclassloader, I’ve got control over it. A clear case of missing good logging.
Currently I’m trying to figure out how to see which locations are available to the ClassPool as that’s driving javassist with the ability to load a particular class (especially since I’ve got an error loading java.util.concurrent.Callable which is a base interface).
I think that I’ll focus on clear logging for the moment to be able to avoid these type of instances.
I’ve ran into another small set back. This time it’s called the java.security.manager.
Compare the following results:
java -DTAINT_LOGGING=true -DTHROW_EXCEPTION=true -Djava.security.manager=jarjar.org.gradle.process.internal.child.BootstrapSecurityManager -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: jarjar.org.gradle.process.internal.child.BootstrapSecurityManager
at sun.misc.Launcher.(Launcher.java:106)
at sun.misc.Launcher.(Launcher.java:57)
at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1489)
at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1474)
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(AbstractTaintUtil.java:46)
at org.owasp.securt.TaintUtil.checkTaint(TaintUtil.java)
at java.io.PrintStream.print(PrintStream.java)
at java.io.PrintStream.println(PrintStream.java:806)
at org.owasp.securt.StandaloneTest.main(StandaloneTest.java:27)
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.
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 {
Class.forName("org.hsqldb.jdbcDriver");
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);
resultSet.close();
statement.close();
connection.close();
fail("Should not get here");
} catch (Exception e) {
System.err.println("Got an exception! ");
System.err.println(e.getMessage());
e.printStackTrace(System.err);
}
}
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 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 = [
"-d",
sourceSets.main.output.classesDir,
"-p"
].toList()
}
}
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.,
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:
<securt>
<sources>
<!--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"/>
</source>
</sources>
<sinks>
<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"/>
</sink>
</sinks>
</securt>
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");
atu.writeFile(destPath);
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));
cc.writeFile(destPath);
}
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 😉
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:
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);
f.setModifiers(Modifier.PRIVATE);
cc.addField(f);
// generate getters and setters for the new field
cc.addMethod(CtNewMethod.getter("isTainted", f));
cc.addMethod(CtNewMethod.setter("setTaint", f));
cc.writeFile(destPath);
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.
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 java.io.PrintStream.print(PrintStream.java:666) at java.io.PrintStream.println(PrintStream.java:807) at SimpleTest.main(SimpleTest.java:15)
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 System.in, I modified BufferedReader.readLine to be as follows:
public String readLine() throws IOException {
String result = readLine(false);
if (result != null)
result.setTaint(true);
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";
}
write(s);
}
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);
result.setTaint(tainted);
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).
Nice.
Thanks to Arshan Dabirsiaghi who made a comment in http://blog.diniscruz.com/2013/09/java-tainted-strings.html 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;
import java.io.*;
public class Basetest {
public static void main(String[] args) {
System.out.print("Enter your name: ");
BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
String userName = null;
try {
userName = br.readLine();
} catch (IOException ioe) {
System.out.println("IO error trying to read your name!");
System.exit(1);
}
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.
