New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Security Policy #24

Closed
floyd-fuh opened this Issue May 8, 2018 · 4 comments

Comments

2 participants
@floyd-fuh

floyd-fuh commented May 8, 2018

Any chance we could support Java Security Policy with JQF? An example is here: https://github.com/floyd-fuh/kelinci/tree/master/examples/commons-imaging . It basically means starting Java with java -Djava.security.manager -Djava.security.policy=java-security-policy.txt, which would then throw an exception if the Java program tries to write to a file that was not specified in the policy (whitelist). In theory it should allow finding vulnerabilities such as Server Side Request Forgery, as the code would throw an exception when the Java program tries to create a socket.

@rohanpadhye

This comment has been minimized.

Show comment
Hide comment
@rohanpadhye

rohanpadhye May 9, 2018

Owner

That's interesting. I don't actually know much about Java's security policies, but you can pass additional JVM options using the environment variable JVM_OPTS. So perhaps something like this should already work:

export JVM_OPTS="-Djava.security.manager -Djava.security.policy=java-security-policy.txt"
./bin/jqf-afl-fuzz ...
Owner

rohanpadhye commented May 9, 2018

That's interesting. I don't actually know much about Java's security policies, but you can pass additional JVM options using the environment variable JVM_OPTS. So perhaps something like this should already work:

export JVM_OPTS="-Djava.security.manager -Djava.security.policy=java-security-policy.txt"
./bin/jqf-afl-fuzz ...
@floyd-fuh

This comment has been minimized.

Show comment
Hide comment
@floyd-fuh

floyd-fuh May 24, 2018

Here's a policy file that seems to be working for me for JQF+Tika:

grant {
//Runtime and Reflect permissions necessary for JQF
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "getenv.ru.vyarus.java.generics.resolver.context.GenericsInfoFactory.cache";

//Property permissions necessary for JQF
    permission java.util.PropertyPermission "ru.vyarus.java.generics.resolver.context.GenericsInfoFactory.cache", "read";
    permission java.util.PropertyPermission "jqf.afl.TIMEOUT", "read";
    permission java.util.PropertyPermission "jqf.traceGenerators", "read";
    permission java.util.PropertyPermission "jqf.tracing.MATCH_CALLEE_NAMES", "read";
    permission java.util.PropertyPermission "jqf.repro.logUniqueBranches", "read";
    permission java.util.PropertyPermission "jqf.logCoverage", "read";
    permission java.util.PropertyPermission "jqf.repro.traceDir", "read";
    permission java.util.PropertyPermission "jqf.repro.logUniqueBranches", "read";

//File permissions for afl-fuzz
    permission java.io.FilePermission "/tmp/-", "read, write, delete";
    permission java.io.FilePermission "tika-corpus-only-small/-", "read";
    permission java.io.FilePermission "tika-out/-", "read, write";
    permission java.io.FilePermission "tika-out2/-", "read, write";
    permission java.io.FilePermission "tika-out3/-", "read, write";

//File permissions for Tika
    permission java.io.FilePermission "/opt/jqf/examples/target/dependency/tika-core-1.18.jar", "read";
    permission java.io.FilePermission "/opt/jqf/examples/target/dependency/tika-parsers-1.18.jar", "read";

//Runtime permissions for Tika
    permission java.lang.RuntimePermission "getenv.TIKA_CONFIG";

//Property permissions for Tika
    permission java.util.PropertyPermission "org.apache.tika.service.error.warn", "read";
    permission java.util.PropertyPermission "tika.config", "read";
    permission java.util.PropertyPermission "tika.custom-mimetypes", "read";

//Property permissions for Tika dependencies
    permission java.util.PropertyPermission "org.apache.pdfbox.pdfparser.nonSequentialPDFParser.eofLookupRange", "read";
    permission java.util.PropertyPermission "org.apache.pdfbox.forceParsing", "read";
    permission java.util.PropertyPermission "pdfbox.fontcache", "read";
    permission java.util.PropertyPermission "file.encoding", "read";
    //WTF
    permission java.util.PropertyPermission "user.home", "read";
    //WTF
    permission java.util.PropertyPermission "com.healthmarketscience.jackcess.resourcePath", "read";
    permission java.util.PropertyPermission "com.healthmarketscience.jackcess.brokenNio", "read";
    permission java.util.PropertyPermission "com.healthmarketscience.jackcess.charset.VERSION_3", "read";
    permission java.util.PropertyPermission "com.healthmarketscience.jackcess.columnOrder", "read";
    permission java.util.PropertyPermission "com.healthmarketscience.jackcess.enforceForeignKeys", "read";
    permission java.util.PropertyPermission "com.healthmarketscience.jackcess.allowAutoNumberInsert", "read";
    permission java.util.PropertyPermission "com.healthmarketscience.jackcess.timeZone", "read";
    //WTF
    permission java.util.PropertyPermission "com.ctc.wstx.returnNullForDefaultNamespace", "read";
};

Keep in mind that this is a trial-and-error whitelist policy created for the corpus I have. Parts of the code I don't reach with my corpus might need more permissions.

Performance seems to be fine too, on the new x86 machine I get around 10 execs/sec without the policy and with the policy.

However, it seems to me that with the policy, less paths are found (maybe it's just coincidence). Is there a good explanation for that?

And is it normal that jqf.log has exceptions in it such as the followin?

[JANALA] Error instrumenting class org/apache/tika/config/ServiceLoader
java.lang.RuntimeException: Cannot handle jumps before super/this
        at janala.instrument.SnoopInstructionMethodAdapter.visitJumpInsn(SnoopInstructionMethodAdapter.java:846)
        at org.objectweb.asm.ClassReader.readCode(ClassReader.java:1481)
[...]
[JANALA] Error instrumenting class javax/xml/parsers/FactoryFinder
java.lang.RuntimeException: java.io.IOException: Cannot create ClassReader for type java/util/Properties
        at janala.instrument.SafeClassWriter.getCommonSuperClass(SafeClassWriter.java:100)
        at org.objectweb.asm.ClassWriter.getMergedType(ClassWriter.java:1729)
        at org.objectweb.asm.Frame.merge(Frame.java:1530)
        at org.objectweb.asm.Frame.merge(Frame.java:1429)
[...]

floyd-fuh commented May 24, 2018

Here's a policy file that seems to be working for me for JQF+Tika:

grant {
//Runtime and Reflect permissions necessary for JQF
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "getenv.ru.vyarus.java.generics.resolver.context.GenericsInfoFactory.cache";

//Property permissions necessary for JQF
    permission java.util.PropertyPermission "ru.vyarus.java.generics.resolver.context.GenericsInfoFactory.cache", "read";
    permission java.util.PropertyPermission "jqf.afl.TIMEOUT", "read";
    permission java.util.PropertyPermission "jqf.traceGenerators", "read";
    permission java.util.PropertyPermission "jqf.tracing.MATCH_CALLEE_NAMES", "read";
    permission java.util.PropertyPermission "jqf.repro.logUniqueBranches", "read";
    permission java.util.PropertyPermission "jqf.logCoverage", "read";
    permission java.util.PropertyPermission "jqf.repro.traceDir", "read";
    permission java.util.PropertyPermission "jqf.repro.logUniqueBranches", "read";

//File permissions for afl-fuzz
    permission java.io.FilePermission "/tmp/-", "read, write, delete";
    permission java.io.FilePermission "tika-corpus-only-small/-", "read";
    permission java.io.FilePermission "tika-out/-", "read, write";
    permission java.io.FilePermission "tika-out2/-", "read, write";
    permission java.io.FilePermission "tika-out3/-", "read, write";

//File permissions for Tika
    permission java.io.FilePermission "/opt/jqf/examples/target/dependency/tika-core-1.18.jar", "read";
    permission java.io.FilePermission "/opt/jqf/examples/target/dependency/tika-parsers-1.18.jar", "read";

//Runtime permissions for Tika
    permission java.lang.RuntimePermission "getenv.TIKA_CONFIG";

//Property permissions for Tika
    permission java.util.PropertyPermission "org.apache.tika.service.error.warn", "read";
    permission java.util.PropertyPermission "tika.config", "read";
    permission java.util.PropertyPermission "tika.custom-mimetypes", "read";

//Property permissions for Tika dependencies
    permission java.util.PropertyPermission "org.apache.pdfbox.pdfparser.nonSequentialPDFParser.eofLookupRange", "read";
    permission java.util.PropertyPermission "org.apache.pdfbox.forceParsing", "read";
    permission java.util.PropertyPermission "pdfbox.fontcache", "read";
    permission java.util.PropertyPermission "file.encoding", "read";
    //WTF
    permission java.util.PropertyPermission "user.home", "read";
    //WTF
    permission java.util.PropertyPermission "com.healthmarketscience.jackcess.resourcePath", "read";
    permission java.util.PropertyPermission "com.healthmarketscience.jackcess.brokenNio", "read";
    permission java.util.PropertyPermission "com.healthmarketscience.jackcess.charset.VERSION_3", "read";
    permission java.util.PropertyPermission "com.healthmarketscience.jackcess.columnOrder", "read";
    permission java.util.PropertyPermission "com.healthmarketscience.jackcess.enforceForeignKeys", "read";
    permission java.util.PropertyPermission "com.healthmarketscience.jackcess.allowAutoNumberInsert", "read";
    permission java.util.PropertyPermission "com.healthmarketscience.jackcess.timeZone", "read";
    //WTF
    permission java.util.PropertyPermission "com.ctc.wstx.returnNullForDefaultNamespace", "read";
};

Keep in mind that this is a trial-and-error whitelist policy created for the corpus I have. Parts of the code I don't reach with my corpus might need more permissions.

Performance seems to be fine too, on the new x86 machine I get around 10 execs/sec without the policy and with the policy.

However, it seems to me that with the policy, less paths are found (maybe it's just coincidence). Is there a good explanation for that?

And is it normal that jqf.log has exceptions in it such as the followin?

[JANALA] Error instrumenting class org/apache/tika/config/ServiceLoader
java.lang.RuntimeException: Cannot handle jumps before super/this
        at janala.instrument.SnoopInstructionMethodAdapter.visitJumpInsn(SnoopInstructionMethodAdapter.java:846)
        at org.objectweb.asm.ClassReader.readCode(ClassReader.java:1481)
[...]
[JANALA] Error instrumenting class javax/xml/parsers/FactoryFinder
java.lang.RuntimeException: java.io.IOException: Cannot create ClassReader for type java/util/Properties
        at janala.instrument.SafeClassWriter.getCommonSuperClass(SafeClassWriter.java:100)
        at org.objectweb.asm.ClassWriter.getMergedType(ClassWriter.java:1729)
        at org.objectweb.asm.Frame.merge(Frame.java:1530)
        at org.objectweb.asm.Frame.merge(Frame.java:1429)
[...]
@rohanpadhye

This comment has been minimized.

Show comment
Hide comment
@rohanpadhye

rohanpadhye May 28, 2018

Owner

The exceptions in the log file that you see are due to the inability of JQF to instrument some classes, due to code patterns such as those described in #22. Unfortunately, this means that those classes will not be instrumented (and branches in their methods will not be recorded). However, it is fine in that JQF will just skip those classes and instrument everything else that it can.

As to why you are seeing fewer paths with the use of the policy, I cannot say for sure. As I said, I don't have much experience with security policies in Java, but perhaps I can try reproducing your experiment to see if I can find any anomalies.

Owner

rohanpadhye commented May 28, 2018

The exceptions in the log file that you see are due to the inability of JQF to instrument some classes, due to code patterns such as those described in #22. Unfortunately, this means that those classes will not be instrumented (and branches in their methods will not be recorded). However, it is fine in that JQF will just skip those classes and instrument everything else that it can.

As to why you are seeing fewer paths with the use of the policy, I cannot say for sure. As I said, I don't have much experience with security policies in Java, but perhaps I can try reproducing your experiment to see if I can find any anomalies.

@floyd-fuh

This comment has been minimized.

Show comment
Hide comment
@floyd-fuh

floyd-fuh Jun 27, 2018

I just wanted to let you know that I ran JQF instances with Java Security Policy by default now and they seem to run fine. The lesser paths issue might have been random differences and not related to the Security Policy.

floyd-fuh commented Jun 27, 2018

I just wanted to let you know that I ran JQF instances with Java Security Policy by default now and they seem to run fine. The lesser paths issue might have been random differences and not related to the Security Policy.

@floyd-fuh floyd-fuh closed this Jun 27, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment