Skip to content
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
Closed

Feature request: Security Policy #24

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

Comments

@floyd-fuh
Copy link
Contributor

@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
Copy link
Owner

@rohanpadhye 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
Copy link
Contributor Author

@floyd-fuh 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
Copy link
Owner

@rohanpadhye 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
Copy link
Contributor Author

@floyd-fuh 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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.