@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.

Delete Deprecated Log4J implementation and Dependencies #534

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions