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 😉
