Scheduling removal of Log4J 1 from ESAPI 2.x

[Kevin W. Wall]

The ESAPI deprecation policy (barring some critical or high vulnerability that has no workaround) is that we will leave the deprecated class or method around until either:

1. The next major release (which would be 3.0.0.0 and it not yet scheduled) OR
2. Two years after the release date in which it was first deprecated.

Since we officially deprecated Log4J 1 in ESAPI version 2.2.1.0 that was released on July 12, 2020, we will be scheduling it for complete removal on or shortly after July 12, 2022 even if it requires a special release to do so.

Please plan accordingly as July is not that far off. (And for us, it can't come too soon! :)

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

[Olivier Jaquemet]

Hi all,

 In case you missed this information, you can replace log4j 1.x, in any project without any code change, by using reload4j: a binary compatible distrib maintained by the original author of log4j, without any vulnerabilities.

https://reload4j.qos.ch/

--
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/CAOPE6PiZz79Sfwo0AS6kfgmo0ESmaRU6F91-SHYoRYrhGmnjNg%40mail.gmail.com.

[Kevin W. Wall]

Thanks, I wasn't aware of that. It may work for a short term replacement (we'll have to check) until July, but we still are planning to remove it from ESAPI, in part to just reduce the complexity in our code base.

-kevin

[Jeremiah Stacey]

For the ongoing ESAPI development, I'm not sure the juice is worth the squeeze as we roll forward this year.  Once the log4j-1.x support is removed it won't make a difference which implementation is on an application's path.

My opinion would be for any projects that intend to continue using ESAPI going forward look into updating to Slf4JLogFactory in the ESAPI configurations and get ahead of the conversion.
https://github.com/ESAPI/esapi-java-legacy/wiki/Using-ESAPI-with-SLF4J

This visibility could not come at a better time though, since ESAPI just published the final java 7 version of the library.  I think this is a fantastic option for anyone who is going to be required to stay on java 7, and is configured to use log4j-1.x. (still, update to slf4j if possible)

If I were in this scenario, in addition to the path configuration listed I think I would also explicitly exclude the log4j-1.x dependency from ESAPI, or mark the dependency in my project pom's <dependencyManagment> section as 'provided' scope so the original log4j-1.x reference is not bundled with my application content.  The additional project configuration should guarantee that the reload4j reference is the one that gets loaded.

That all being said, I think that this would be small change to perform.  If there are projects who intend to use ESAPI as we move forward with java8, and simply cannot afford the conversion to slf4j in the short term, then I do not believe there is a functional reason why ESAPI would not be able to support this and bundle with the reload4j reference as part of the project.  If it's needed we can try to provide it as a default project configuration for the next few months; alternatively, the path solution is also completely viable.

I would expect that any baseline change would only be for the active develop branch, and  would not be back-ported to the last java7 release.  It will also be part of the removal when the Log4j-1.x support is cleaned up.

Unless this is explicitly requested my preference would be to not do this work in the ESAPI baseline.

-Jeremiah

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

[Kevin W. Wall]

Jeremiah,

Thanks for weighing in on this. If there are no new CVEs published against Log4J 1 between now and July 13th target date for a release without log4j support AT ALL (I originally said 7/12, but Maven Central said 7/13, so I'll allow all of the log4j 1 holdouts an extra day), then I agree, it's not much of a win for us or anyone else. (Although, AFAICT, the effort should be pretty trivial on our side; just a pom.xml change, and a new release.)

BUT, if there are new CVEs published between now and 7/13, then I may very well change my mind without any advance notice. We've already written up 6 ESAPI Security Bulletins for Log4J 1 related CVEs alone. And recently (Feb / March I think) 3 new CVEs for it were dropped. If something like that happens again, I definitely will be putting out a release with the latest reload4j release replacing log4j-1.2.17.jar. The write-up and proof-reading of one of those bulletins typically takes me 3 or 4 hours and that's when I have a similar one to go back on. And that doesn't include time to research the vulnerability, which often involves crawling through the bowels of the log4j-1.2.17 source and comparing it to how ESAPI uses it to see if there is any exploitable path. When I need to do that, that can add anywhere from 1 to 4 more hours. So you can bet I will be choosing reload4j over writing up 3 more ESAPI Security Bulletins. And the way things have been going, it wouldn't surprise me if we see 5 or 6 more CVEs reported against Log4J 1.

I do realize that's not going to be a panacea. If ESAPI clients have applications directly using Log4J 1 in the application as well as via ESAPI, having ESAPI replace log4j-1.2.17.jar with the latest reload4j jar, but having the application team leaving the direct log4j 1 dependency in their classpath means problems could still be manifested via ESAPI (assuming of course there was an exploitable path). That's because you couldn't really be sure which of the 2 jars your classloader would happen to pick up and since they contain they same package & class names (and probably manifest?), once one jar is loaded, the other jar likely wouldn't be (unless perhaps by a different class loader). So that all gets messy and we'd probably try to explain it in the release notes. But it helps everyone with the false positives in their SCA tools and might get their management and security teams off their backs.

But for now, I'm okay with waiting as long as Log4J doesn't cause me any more pain.

-kevin

To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/esapi-project-users/9264ca35-c486-a59b-d117-cbf7ca7878cd%40gmail.com.

[Simon McClenahan]

reload4j seems similar to the slf4j bridge that I have mentioned previously.

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