A word about Log4J vulnerabilities in ESAPI - the TL;DR version

[Kevin W. Wall]

There have been several people, rightfully concerned about recent Log4J vulnerabilities, asking the ESAPI maintainers in private emails if ESAPI is vulnerable. This is an attempt to answer this once for all rather than having to reply to every concerned person individually.

The TL;DR Executive Summary:

1. We have no intention of dropping support for Log4J 1 in ESAPI 2.x. (ESAPI has no dependency on Log4J 2.) The reason for this is we need to support backwards compatibility for our clients.
2. There is a possibility that you could use ESAPI in a manner that makes it vulnerable to the multiple Log4J 2 CVEs if you configure ESAPI to use SLF4J along with an unpatched version of Log4J 2. ESAPI has zero control over that and can't protect you from it.
3. When we eventually develop and release ESAPI 3.x, it absolutely will not have direct support for Log4J. Not. At. All. In ESAPI 3, we only plan to support SLF4J and no particular implementation, so that the only SLF4J dependency will be the slf4j-api jar. (But ESAPI 3 is still a long way off.) [Yes, that means we likely will also drop direct support for JUL as well.]
   
4. You really should NOT just skip the remaining details.

An Important Point to Understand:

Every vulnerability that is included as a dependency in your code base (including those associated with critical CVEs), does not automatically make that vulnerability exploitable in every application. There must be an exploitable path. So for instance, imagine the following hypothetical scenario. Suppose the HappyPappy SecretSauce security library has a vulnerability in the class method HoldMyBeer.watchThis(String). If that class (or more accurately, in this hypothetical example, that class' watchThis() method) has no possible way to ever be invoked in your application code base, then there is no exploitable path for you. But keep in mind that Software Composition Analysis (SCA) tools simply look for dependencies of outdated and/or unpatched libraries; they don't analyze execution paths so they may raise false alerts.

Using any library with known unpatched vulnerabilities (much less one using a library that is past its end of life and will likely never be patched again) will not make your SCA tools happy. In general, is not something that any of the ESAPI maintainers would recommend either, but there is a balance for library maintainers of balancing risk versus keeping backward compatibility for the benefit of our clients. We have strived to maintain that balance.

The Details / Rationale of "Why Log4J 1?"

We are aware that:

1. Log4J 1.x is past EOL and no longer supported. You don't need to keep reminding us.
   
2. That Log4J 1.2.17 (that last 1.x release) has at least 3 known CVEs associated with it:
   

• CVE-2019-17571, CVVSv3.1 base score 9.8 (Critical), associated with the Log4J SocketServer class. This was addressed in ESAPI release notes as well as in the separate Security Bulletin #2.
• CVE-2020-9488, CVSSv3.1 base score 3.7 (Low), associated with the SMTPAppender class. This was addressed in ESAPI release notes as well as in the separate Security Bulletin #4.
• CVE-2021-4104, CVSSv3.1 base score 8.1 (High), associated with the JMSAppender class. This was addressed in the recently announced Security Bulletin #6.
  

Long ago, Log4J 1.x used to be the default configured logger in ESAPI. We gave advance notice (probably about 6 months) that we were dropping support for it as the DEFAULT logger and we changed ESAPI's default logger to be java.util.logging (JUL). In our release notes, we caution people not to use Log4J 1. We marked its use as deprecated. In the 3 security bulletins, we even describe to developers how they can use ESAPI and exclude the log4j 1.2.17 dependency from their application completely. But we still get asked about "getting rid of the unsupported Log4J 1 and plans on upgrading to Log4J 2 in ESAPI".  We have NO plans to do so because:

1. If we remove Log4J 1.x, that will break some of ESAPI clients' code.  We might reconsider or do some drastic workaround like requiring a System property be set to 'true' if a known vulnerability in Log4J 1.x that appears to be exploitable through the latest ESAPI 2.x release appears. Or we may even try to address the CVE in ESAPI by patching it and including the patch as part of ESAPI. Right now, it  doesn't seem to be the case that there are any known vulnerabilities through the default Log4J 1 configuration of ESAPI. (Although, as former Secretary of Defense, Donal Rumsfeld, pointed out it is the "unknown unknowns", the things that we do not know we don't know, that can really hurt you.) This we wish to balance the risk vs the inconvenience of to our clients, and we believe we have done that by making it so that Log4J 1 is no longer the ESAPI logger and providing options (via SLF4J) for clients to use the modern and still supported Log4J 2. We will just have to play that by ear if we find a case where the default configuration with Log4J 1 in ESAPI is impacted and we believe that risk is unacceptable.
   
2. Because clients can still use Log4J 2 via SLF4J, we have no plans to replace Log4J 1 with Log4J 2.  

Finally, if you decide to use SLF4J with Log4J 2, make sure that you use the latest patched Log4J 2 jars. Because you are all smart enough to be using a security library like ESAPI in the first place, we assume that you also know how to monitor for vulnerabilities in your application dependencies and patch when new versions are released. The SLF4J site, http://www.slf4j.org/log4shell.html has a good explanation of how to avoid this.

Also, it is IMPORTANT that you read the release notes for new releases, especially when we have sections like "Changes Requiring Special Attention". When people change loggers, that is the biggest point that they miss and those instructions are almost always covered in the release notes.

Thanks,
-kevin

--

Blog: https://off-the-wall-security.blogspot.com/    | Twitter: @KevinWWall | OWASP ESAPI Project co-lead
NSA: All your crypto bit are belong to us.

[Simon McClenahan]

To "remove Log4J" means to remove it as a direct compile-time dependency from the project (or POM), so that it doesn't trigger all the SCA and code-scanning tools becoming much more commonplace nowadays.

On Saturday, December 18, 2021 at 4:16:34 PM UTC-6 kevin....@gmail.com wrote:

1. If we remove Log4J 1.x, that will break some of ESAPI clients' code.  We might reconsider or do some drastic workaround like requiring a System property be set to 'true' if a known vulnerability in Log4J 1.x that appears to be exploitable through the latest ESAPI 2.x release appears. Or we may even try to address the CVE in ESAPI by patching it and including the patch as part of ESAPI. Right now, it  doesn't seem to be the case that there are any known vulnerabilities through the default Log4J 1 configuration of ESAPI. (Although, as former Secretary of Defense, Donal Rumsfeld, pointed out it is the "unknown unknowns", the things that we do not know we don't know, that can really hurt you.) This we wish to balance the risk vs the inconvenience of to our clients, and we believe we have done that by making it so that Log4J 1 is no longer the ESAPI logger and providing options (via SLF4J) for clients to use the modern and still supported Log4J 2. We will just have to play that by ear if we find a case where the default configuration with Log4J 1 in ESAPI is impacted and we believe that risk is unacceptable.

From https://www.slf4j.org/legacy.html

log4j-over-slf4j

SLF4J ship with a module called log4j-over-slf4j. It allows log4j users to migrate existing applications to SLF4J without changing a single line of code but simply by replacing the log4j.jar file with log4j-over-slf4j.jar, as described below.To use log4j-over-slf4j in your own application, the first step is to locate and then to replace log4j.jar with log4j-over-slf4j.jar. Note that you still need an SLF4J binding and its dependencies for log4j-over-slf4j to work properly.

In most situations, replacing a jar file is all it takes in order to migrate from log4j to SLF4J.

 

[Matt Seil]

On 12/23/2021 2:03 PM, Simon McClenahan wrote:

To "remove Log4J" means to remove it as a direct compile-time dependency from the project (or POM), so that it doesn't trigger all the SCA and code-scanning tools becoming much more commonplace nowadays.

That is not true. 

As stated earlier, we require several classes from Log4j at compile time in order to maintain our ability to map ESAPI logging to legacy log4j-dependent ESAPI behavior.  Specifically (but not limited to) we need the Logger class.  There are two reasons its needed, the first, the aforementioned log wrapper.  The second is that it's needed in order to create ESAPi's Log4j LogFactory itself.  If we don't specify our own LogFactory, then we have no ability to control Log4j execution--at all.  That's a function of how log4J 1.X's implementation was written and we can't change that until we reach our deprecation time period and we just delete it all. 

I stand behind what Kevin stated earlier that the only way you're going to be vulnerable through ESAPI is if you explicitly configure ESAPI to use log4j.  The only way an attacker could accomplish this is if they can inject a vulnerable copy of log4J into ESAPI's configuration which means they have to have the ability to write to your filesystem and restart your webserver -->  You've got bigger problems. 

Your comment on SCA tools sorta sets me off--this is a false positive in ESAPI's case.  Yes, we are dependent on a version of log4j, but we don't use any of the vulnerable functionality even if you configure a log4j 1.X instance to use with ESAPI.  We don't use JNDI, period.  The lead author of log4j 1.X says "Log4j 1.x does not offer a look up mechanism. Log4j 1.x sends an event encapsulating a string message to a JMS server. That is it. The attacker can supply whatever string he chooses but it remains a String. So not the same. At all."

So if SAST tools are reporting ESAPI as vulnerable, that's because they didn't do their homework.  SHOULD you use log4j 1.X?  Nope.  But as we're not vulnerable log4shell unless you configure ESAPI to use an affected version of log4j 2.X, we're fine. 

I'm totally baffled as to why you'd think this.  I know this intimately as I've converted applications from log4j 1.X to slf4j (and in one instance, from slf4j back to log4j.)  Whoever told you that was wrong. 

slf4j was created after log4j 1.X as a means of creating a unified java logging interface;  this is why log4j-over-slf4j exists in order to give you a concrete way to code slf4j and use log4j as the implementation.  You would also need to change all of your code imports from org.apache.log4j.Logger to org.apache.slf4j.Logger at a bare minimum. 

 

--
You received this message because you are subscribed to the Google Groups "ESAPI Project Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to esapi-project-u...@owasp.org.
To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/esapi-project-users/08cc21c7-b2f3-4446-b89b-5110081345b2n%40owasp.org.

[Kevin W. Wall]

One thing to add... the Security Bulletins that I mentioned in the original email that cover the Log4J 1.x related CVEs discuss how client applications that are not using Log4J for ESAPI logging can explicitly exclude the log4j-1.2.17.jar so that their SCA tools don't give false positives. But as Matt (and I thought I as well) made clear, ESAPI has direct compile-time dependencies on Log4J:

$ grep -rl org.apache.log4j src/main

src/main/java/org/owasp/esapi/logging/log4j/Log4JLogBridge.java
src/main/java/org/owasp/esapi/logging/log4j/Log4JLogBridgeImpl.java
src/main/java/org/owasp/esapi/logging/log4j/Log4JLogFactory.java
src/main/java/org/owasp/esapi/logging/log4j/Log4JLogLevelHandler.java
src/main/java/org/owasp/esapi/logging/log4j/Log4JLogLevelHandlers.java
src/main/java/org/owasp/esapi/logging/log4j/Log4JLoggerFactory.java
src/main/java/org/owasp/esapi/logging/log4j/Log4JLogger.java
src/main/java/org/owasp/esapi/waf/ESAPIWebApplicationFirewallFilter.java
src/main/java/org/owasp/esapi/waf/configuration/AppGuardianConfiguration.java

@Matt Seil and @Jeremiah J. Stacey - We may want to check those last too and see if we can get rid of the Log4J dependencies. The last one just uses org.apache.log4j.Level, so it can probably be replaced by an enum that Jeremiah created somewhere. But the ESAPIWebApplicationFirewallFilter.java may be a bit trickier, as it imports org.apache.log4j.xml.DOMConfigurator. Not sure we can find a substitute in some other Apache Commons jar we include or just pull in the (hopefully small) set of necessary classes directly into ESAPI.  Looks like I already have created a GitHub issue for this (https://github.com/ESAPI/esapi-java-legacy/issues/595) a while back.

@Simon McClenahan - If you are still looking for something to work on, that is labeled as 'Good First Issue'. :)

-kevin

[David Karr]

On Sat, Dec 18, 2021 at 2:16 PM Kevin W. Wall <kevin....@gmail.com> wrote:

There have been several people, rightfully concerned about recent Log4J vulnerabilities, asking the ESAPI maintainers in private emails if ESAPI is vulnerable. This is an attempt to answer this once for all rather than having to reply to every concerned person individually.

The TL;DR Executive Summary:

1. We have no intention of dropping support for Log4J 1 in ESAPI 2.x. (ESAPI has no dependency on Log4J 2.) The reason for this is we need to support backwards compatibility for our clients.
2. There is a possibility that you could use ESAPI in a manner that makes it vulnerable to the multiple Log4J 2 CVEs if you configure ESAPI to use SLF4J along with an unpatched version of Log4J 2. ESAPI has zero control over that and can't protect you from it.
3. When we eventually develop and release ESAPI 3.x, it absolutely will not have direct support for Log4J. Not. At. All. In ESAPI 3, we only plan to support SLF4J and no particular implementation, so that the only SLF4J dependency will be the slf4j-api jar. (But ESAPI 3 is still a long way off.) [Yes, that means we likely will also drop direct support for JUL as well.]
   
4. You really should NOT just skip the remaining details.

An Important Point to Understand:

Every vulnerability that is included as a dependency in your code base (including those associated with critical CVEs), does not automatically make that vulnerability exploitable in every application. There must be an exploitable path. So for instance, imagine the following hypothetical scenario. Suppose the HappyPappy SecretSauce security library has a vulnerability in the class method HoldMyBeer.watchThis(String). If that class (or more accurately, in this hypothetical example, that class' watchThis() method) has no possible way to ever be invoked in your application code base, then there is no exploitable path for you. But keep in mind that Software Composition Analysis (SCA) tools simply look for dependencies of outdated and/or unpatched libraries; they don't analyze execution paths so they may raise false alerts.

Using any library with known unpatched vulnerabilities (much less one using a library that is past its end of life and will likely never be patched again) will not make your SCA tools happy. In general, is not something that any of the ESAPI maintainers would recommend either, but there is a balance for library maintainers of balancing risk versus keeping backward compatibility for the benefit of our clients. We have strived to maintain that balance.

The Details / Rationale of "Why Log4J 1?"

We are aware that:

1. Log4J 1.x is past EOL and no longer supported. You don't need to keep reminding us.
   
2. That Log4J 1.2.17 (that last 1.x release) has at least 3 known CVEs associated with it:
   

• CVE-2019-17571, CVVSv3.1 base score 9.8 (Critical), associated with the Log4J SocketServer class. This was addressed in ESAPI release notes as well as in the separate Security Bulletin #2.
• CVE-2020-9488, CVSSv3.1 base score 3.7 (Low), associated with the SMTPAppender class. This was addressed in ESAPI release notes as well as in the separate Security Bulletin #4.
• CVE-2021-4104, CVSSv3.1 base score 8.1 (High), associated with the JMSAppender class. This was addressed in the recently announced Security Bulletin #6.
  

Long ago, Log4J 1.x used to be the default configured logger in ESAPI. We gave advance notice (probably about 6 months) that we were dropping support for it as the DEFAULT logger and we changed ESAPI's default logger to be java.util.logging (JUL). In our release notes, we caution people not to use Log4J 1. We marked its use as deprecated. In the 3 security bulletins, we even describe to developers how they can use ESAPI and exclude the log4j 1.2.17 dependency from their application completely. But we still get asked about "getting rid of the unsupported Log4J 1 and plans on upgrading to Log4J 2 in ESAPI".  We have NO plans to do so because:

I may have missed it, but can someone tell me what version of ESAPI no longer has log4j as the default logger?

[Kevin W. Wall]

David,

In release 2.2.1.0, we switched from log4J 1.x as being the default ESAPI logger to JUL (java.util.logging).

It was mentioned in those release notes as well as in Security Bulletin #2.

-kevin

--
You received this message because you are subscribed to the Google Groups "ESAPI Project Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to esapi-project-u...@owasp.org.

To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/esapi-project-users/CAA5t8Vpzo93x4FtAYg21GUmKrWi9h-zpwMHZY%3DXFH4w4ZJqBiQ%40mail.gmail.com.

[Kevin W. Wall]

I just created a new Security Bulletin #7 to address CVE-2022-23305, a new Log4J 1 (of course!) vulnerability.

This one is a SQL Injection. No CVSS score assigned by NIST NVD, but Snyk assigned it an 8.1.

ESAPI default configuration is safe. You should only be vulnerable if you have ESAPI.Logger configured to use Log4J 1 and in your Log4J configuration file (log4j.xml or log4j.properties), you are using JDBCAppender to send your logs to a database.

Details are in the security bulletin.

-kevin