5 ms·

> without nonstandard log4j back-end configuration By "nonstandard" do you mean different than default settings? It looks like they changed the default as of v

> without nonstandard log4j back-end configuration By "nonstandard" do you mean different than default settings? It looks like they changed the default as of v2.15: https://issues.apache.org/jira/browse/LOG4J2-3198 https://issues.apache.org/jira/browse/LOG4J2-3198 For earlier versions (2.10+) it looks like there's a single setting you can toggle to prevent the lookup behavior: log4j2.formatMsgNoLookups=true (or env var LOG4J_FORMAT_MSG_NO_LOOKUPS=true)

ollien 5y ago
Correct me if I'm wrong, but this means that an application with version 2.15 installed can still be vulnerable, yes?
- layer8 5y ago
  Not really, because log4j now restricts JNDI-LDAP queries to localhost by default, or to an explicitly configured list of hosts. An attacker would have to have access to the application configuration or start script.
  - staticassertion 5y ago
    No, you are still vulnerable, even with just what we know today and we're still finding more ways to break this library. 1. Attackers can still load code in your class path. 2. Attackers can steal environment variables, VM information, system information, etc. 3. The issue isn't specific to LDAP in any way, that was just a particularly brutal way to exploit this vulnerability. There are other ways to achieve RCE. We may find even more ways to attack this in the future. It is absolutely not a good idea to assume you're safe right now - if you have log4j in your dependency tree, you should keep a close eye on the discourse as it evolves. edit: I'll just say that I think it's really premature to tell anyone that they're safe.
    - layer8 5y ago
      As far as log4j is concerned, the substitutions ("lookups" — this includes your #2) are now disabled by default, and can only be enabled by an attacker if he already has access to the application. I’m not sure what you’re referring to in #1 and #3, given that fix.
layer8 5y ago
Yes, it’s good that they changed the default now. But it’s still a design mistake that they can’t distinguish between the log pattern, log message format and logging parameters. If you turn it on, it’s turned on on everything, because the substitution is performed as the last step.

ollien 5y ago

Correct me if I'm wrong, but this means that an application with version 2.15 installed can still be vulnerable, yes?

layer8 5y ago
Not really, because log4j now restricts JNDI-LDAP queries to localhost by default, or to an explicitly configured list of hosts. An attacker would have to have access to the application configuration or start script.
- staticassertion 5y ago
  No, you are still vulnerable, even with just what we know today and we're still finding more ways to break this library. 1. Attackers can still load code in your class path. 2. Attackers can steal environment variables, VM information, system information, etc. 3. The issue isn't specific to LDAP in any way, that was just a particularly brutal way to exploit this vulnerability. There are other ways to achieve RCE. We may find even more ways to attack this in the future. It is absolutely not a good idea to assume you're safe right now - if you have log4j in your dependency tree, you should keep a close eye on the discourse as it evolves. edit: I'll just say that I think it's really premature to tell anyone that they're safe.
  - layer8 5y ago
    As far as log4j is concerned, the substitutions ("lookups" — this includes your #2) are now disabled by default, and can only be enabled by an attacker if he already has access to the application. I’m not sure what you’re referring to in #1 and #3, given that fix.

layer8 5y ago

Yes, it’s good that they changed the default now. But it’s still a design mistake that they can’t distinguish between the log pattern, log message format and logging parameters. If you turn it on, it’s turned on on everything, because the substitution is performed as the last step.