Delete Deprecated Log4J implementation and Dependencies

[jeremiahjstacey]

In future releases the log4j dependencies and esapi logger implementation & packages should be removed from the project.

Last released version is 2.2.0.0.

[jeremiahjstacey]

@kwwall @xeno6696 I know we don't want to do this before we release again, but I wanted to ensure the intent was captured. Please extend the description as needed. I'm sure we want to wait until at least v 2.2.0.1 before moving forward with this cleanup.

[kwwall]

We formerly had an unofficial deprecation policy that said we would not REMOVE anything that we had marked as deprecated until EITHER: 1) A minimum of 2 years, Or 2) The next MAJOR release number. whichever comes first. I recently updated our README.MD file to make that policy official (although, I may not have pushed that commit yet; will have to check). Previously you could only find that if you went back to some very early release notes. The last time we actually deleted deprecated code, if fell under condition #1. (2.1.0.1 was released more than 2 years earlier than 2.2.0.0.) Since that won't happen this time around (would like to do another release soon), we likely will have to wait until the 3.0 release to actually formally dump log4j 1.x. Since that will be awhile, my plan is to write up a Security Bulletin about this and reference it in the release notes as well as from the README.MD. I'm working on the Security Bulletin now.

[EddyVos]

I want to add something to this. We also have some issues with the old log4J 1.2.17 that is in use with esapi-2.2.0.0. Our Nexus-IQ is blocking our build since Log4J 1.2.17 has a Level 9 issue ( CVE-2019-17571 ). I upgraded our application to log4J 2.x but it fails building since ESAPI is still using the old log4j with a loggerFactory. (ClassNotFoundException)

Any change that ESAPI 3.x will be released soon?

[xeno6696]

@EddyVos no answer yet on ESAPI 3.0 but there are active changes in the current development branch to remove Log4j 1.X.

[kwwall]

@jeremiahjstacey - Please jump if here if I understand this incorrectly, but for the moment--in the spirit of deprecation--the old log4j 1.x functionality is still available, and the ESAPI log4j class names have simply been reorganized to move to a alternate package name. But the important thing is that the log4j 1.x logging is still available if someone actually needs to continue to use it. To do so, instead of setting:
    ESAPI.Logger=org.owasp.esapi.reference.Log4JLogFactory
in your ESAPI.properties file, one would set it to:
    ESAPI.Logger=org.owasp.esapi.logging.log4j.Log4JLogFactory

That is, most (all?) of the log4j 1.x related implementation classes have been moved (renamed) from "org.owasp.esapi.reference" to "org.owasp.esapi.logging.log4j". So, to @xeno6696's point, I don't think we really removed them but really (for now) just renamed them. (The implementations of those renamed classes may have changed somewhat, but the overall functionality of using log4j 1.x logging should still be available.)

Technically, that could still break peoples could (remind me to mention that when I write up the next release notes) if applications are referencing those deprecated log4j 1 ESAPI classes directly, but generally developers should NOT be directly using reference classes in their code base. Instead, of the implementation (reference) classes, they ought to be working through the interfaces and abstract classes, and factories, etc.

@EddyVos - At a future time (either ESAPI 3.0--which will be our next major release, or two years from the next point release--whichever comes first), we will actually delete all the log4j deprecated classes and thus the log4j 1.x dependency, but unfortunately, until then, any Software Composition Analysis (SCA) tools / services such as OWASP Dependency Check, Black Duck, Nexus-IQ, SourceClear, and several others will continue to squawk "Danger Will Robinson". So unfortunately, at that point, other than either suppressing or ignoring that warning, there's not much you can do.

I am in the process of writing up a full-blown Security Bulletin that will address this, but I have looked at the vulnerable Log4j 1.x class and ESAPI does not use that vulnerable class. Our default implementation only ever used ConsoleAppender, but even if you changed that to one of log4j's FileAppender related classes, they should be safe. The use of log4j 1.x with ESAPI as configured by default will not expose you to this vulnerability described in CVE-2019-1757. (The danger of course is that if you have log4j 1.x in you class path, another developer could start using it in a manner that does make your application vulnerable, but that goes beyond ESAPI.) If your management is uneasy, you will need to communicate to them that it is a false positive (not the vulnerability per se, but in the context of ESAPI and how ESAPI uses it) and refer them to the soon to-be-written ESAPI security bulletin which will recommend possible additional actions. Such as repackaging the ESAPI jar and/or your application's .war / .ear file and simply manually removing the log4j-1.2.17.jar class from your deployment and configure ESAPI.Logger to use SLF4J or JUL. (I think you should still be able to use log4j 2.x via SLF4J and its log4J bridge if you remove the log4j 1.x jar. Maybe @jeremiahjstacey can provide additional details.) But with SCA services, this is always going to be somewhat of an issue. Most of their findings are based on unvetted automatic dependency checking and if their is a vulnerable component that you are using--even if it is transitive dependency--the assumption (and IMO, it is the correct assumption) that whatever is using that application is also vulnerable until proven otherwise. I do secure code reviews for my day job and this sort of thing comes up quite frequently. But in this case, after a cursory 30 minute look at the CVE, the exploitable log4j class, and ESAPI's usage of log4j classes, I am convinced that the manner that ESAPI uses log4j does not present an exploitable path to the vulnerability described in CVE-2019-17571.

The important takeaway from this is that APIs and SDKs are not like end applications that can be refactored at will. For SDKs it is important that the providers maintain backwards compatibility as much as possible and when you break from that you do so either in a major release (as determined by semantic versioning) or have something that is actually putting your users at a greater risk than not making the change. @jeremiahjstacey, @xeno6696, and myself had made this decision to deprecate all the log4j 1.x and change the default logger to JUL (after @jeremiahjstacey had added some functionality enhancements to the JUL logging to make it more like log4j logging) even before CVE-2019-17571 became public. We have in the past made security decisions that would potentially break functionality because security concerns of applications using ESAPI outweigh such minor potential incompatibilities. But in this specific case we are not convinced that the way ESAPI uses log4j 1.x makes this CVE exploitable and removing log4j 1.x functionality at this point would not be a minor incompatibility since it is my observation that more than 95% of the applications using ESAPI used it with log4j 1.x over JUL or SLF4J.

[EddyVos]

Hi @kwwall,

I managed to bypass the issue I have with switching to SLF4J. Used the info that was supplied in issue #129

Thanks for your reply! But I will keep track on verison 3.x ! :)

[subhash14580]

Hi @EddyVos ,
In the issue #129 .There is a key value change for the ESAPI.properties file
ESAPI.Logger=org.owasp.esapi.logging.slf4j.Slf4JLogFactory

But slf4j still uses the log4j internally.

Can you help me how to bypass the issue?

[kwwall]

@subhash14580 - I'm not a 100% sure about this, but I think what @EddyVos probably did was configure ESAPI.Logger to use Slf4JLogFactory and then configured SLF4J to use the log4j 2.x bridge. Because the only other way for him to get rid of this is to delete a bunch of classes from the ESAPI jar. (Well, I suppose he could leave the classes and just delete the log4j-1.2.17.jar which would be a whole lot easier.) And if you did that, you could ensure to your management that the CVE has no affect. (Not log4j 1.x in your classpath, no possibility of exploitation, right?)

That said, whatever your SCA service or tool of choice is, it's still going to be squawking about this and I'm pretty sure that that's a problem that we just can't escape without breaking someone else's code. We will be removing log4j 1.x in ESAPI 3.x, but that is only in the planning stage. Another alternative is that you or someone else could fork ESAPI and then release a log4j-less version of ESAPI 2.x now. But we (OWASP) are not going to do that.

I'm eventually planning on writing up a "security bulletin" of sorts to address this, which we feel that ESAPI is not affected by CVE-2019-17571, but that still isn't going to give your management the warm fuzzies. But at least it will be a start so that for SCA services that have a suppression mechanism and are more concerned with accurate results rather than simply sales or spreading FUD, they would at least have a rationale for suppressing it. But it's probably the best we can do for now.

On the other hand, I would appreciate it if @EddyVos would provide more details about his configuration, if only because we could use some decent documentation to point people to for this. (On Stack Overflow, there's already been a few questions about how to set this up. It would be nice to just point them to some standard documentation.) So if he would be so kind to provide that info, I will make sure that he receives due credit for his contribution.

[subhash14580]

@kwwall Thank you for the information.
You said ESAPI 3.x is in planning stage.Is this version uses log4j2 or older versions?
can you give more clarity about the ESAPI 3.x jar ?

[kwwall]

The default (and possibly only?) logger that ESAPI 3.0 will support will be SLF4J. From there, you will be able to pick whatever logger you want to use, whether it is logback or log4j 2.x or whatever SLF4J supports. It's not be decided whether or not we will continue to support JUL or not. @jeremiahjstacey has done a complete rewrite of that, and it does at any additional dependencies, which is a plus, but it does complicate the code base a bit. (Or a lot, if you consider the current conundrum that we have doing internal logging while processing the ESAPI configuration files, where there's a catch-22 and we don't know what the logger will be until we process the configuration so if the configuration fails before that, what do we use to log it.) But I digress. I should have said the EARLY planning stages. We did decide to break away from ESAPI 2.x entirely so out-of-the-box backward compatibility won't be guaranteed, but we also are thinking that we want ESAPI 3.0 and 2.x to co-exist in the same code base, so to do that, we likely will have ESAPI 3.x releases use "org.owasp.esapi3" package names. Nothing is set in stone at all at this point though, but rather than a monolithic approach that ESAPI 2.x and earlier took, we want to modularize it with an ESAPI core library and then add-on components. That way if you only want to use (say) the ESAPI encoders, you ideally would only need to use the ESAPI core jar and the ESAPI encoder jar. Because we want to minimize the number of dependencies that need to be dragged in to use ESAPI. That has been a sore spot in trying to keep those current or looking for replacements when some dependency reaches end-of-life.

[EddyVos]

Hi,
Indeed I used the SLF4JBridgeHandler. I was following these steps: http://www.slf4j.org/api/org/slf4j/bridge/SLF4JBridgeHandler.html

Somehow it didn't pick up the handlers from the properties file so I initiated it using the programmatic installation in the class.

Next to that when I add the dependency of esapi 2.2.0.0 I exclude the artifact of log4j 1.x
This way I don't have it on the classpath.

     <dependency>
      <groupId>org.owasp.esapi</groupId>
      <artifactId>esapi</artifactId>
      <version>2.2.0.0</version>
      <exclusions>
        <exclusion>
          <groupId>log4j</groupId>
          <artifactId>log4j</artifactId>
        </exclusion>
      </exclusions>
    </dependency>

And in the esapi.properties I have this line now:

ESAPI.Logger=org.owasp.esapi.logging.slf4j.Slf4JLogFactory

[kwwall]

In future releases the log4j dependencies and esapi logger implementation & packages should be removed from the project.

Last released version is 2.2.0.0.

I set this for "wait for future". The first release that this Log4J 1 deprecation will be in will (probably) be the still future 2.2.1.0. We then can do the actual remove of these deprecated classes and the Log4J 1 support either 2 years after that 2.2.1.0 release date or in the next major release (3.0). That is in keeping with our deprecation policy.

Also, someone will need to remind me to mention in the 2.2.1.0 release notes that we need to mention the class name changes for ESAPI.Logger if they still want to use Log4J 1.

[Nagish2410]

Hi Kevin, Does ESAPI 3.x resolve log4j issue..Mean to say it can utilize the log4j 2.x.. and if it can utilized then whats the estimate date we can predict.

[kwwall]

@Nagish2410 - Sorry for the delay in answering. ESAPI 3 is still very much in the design phase, if even that far, but I suspect that we likely will only support (maybe) java.utlil.logging and SLF4J. SLF4J as bridges to support most of the other logging frameworks.

In fact, in theory at least (I have not personally tried it), one ought to be able to support Log4J 2.x today by configuring the latest ESAPI 2.x to use SLF4J and then to configure SLF4J to use Log4J 2.x. If you have questions about how to do that, the best place to post them is probably the "esapi-project-users" Google group (to which you must subscribe to post). The details are in our README.md file. Just search for "Mailing lists" there for details of how to subscribe and post.