Version 2.2.3.1 contains 5 vulnerabilities in ESAPI dependencies

[cwienands1]

We recently incorporated ESAPI 2.2.3.1 into a number of Spring Boot services. Dependency Checker now flags all those services with a total of 5 vulnerabilities: 3 blocker, 1 critical, 1 major.

• CVE-2022-23305
• CVE-2022-23302
• CVE-2021-4104
• CVE-2021-35043
• CVE-2019-17571
  Introduced by commons-io, log4j and antisamy.

The same can be seen in the Maven repository:
https://mvnrepository.com/artifact/org.owasp.esapi/esapi/2.2.3.1

I looked at this project's pom.xml but it looks like these dependencies must be pulled in by the parent pom.

[cwienands1]

I just found issue ESAPI/esapi-java#14, which reports the log4j vulnerabilities. However, it does not mention the other two libraries, commons-io and antisamy.

[xeno6696]

CVE-2022-23305 is answered here.
CVE-2022-23302 didn't warrant a security bulletin as our default configuration even if you chose to use log4j 1.X as the logger is safe until the client deliberately configures their environment into a similar state as the bug.
CVE-2021-4104 Answer is here.
CVE-2021-35043 Antisamy is already upgraded to 1.6.5 in the immediate baseline and this fix should go out with the next release.
CVE-2019-17571 is answered here.

I wish I could make my response here some sort of canonical "WIKI" but two points
1.) Please open bug requests against ESAPI 2.X over here at https://github.com/ESAPI/esapi-java-legacy. The other repo is a stub for ESAPI 3.X
2.) By default for a couple years has been to default logging to JUL, our only uses for log4j as a direct dependency is some bridge classes--that are deprecated--you have to extend a class from the log4j 1.x library and there's no other way to do that but to reference the library

Several of the bulletins linked describe how to configure your own builds in maven to exclude particular transitive components, but the log4j 1.X isn't going away today. Legacy compatibility has us forced to keep the minor log4j dependency we DO have for the immediate future, but it will be drop-kicked ASAP. In the short term, you can use the analyses in the security bulletin for those we published, and you can do similar analyses for the handful we didn't write up. For example, if you haven't 1.) Configured ESAPI to use log4j 1.X as its logging implementation, and then 2.) Haven't configured log4J 1.X to use the JDBCAppender

You are not vulerable. It's up to your team how you handle that, but I write that up as a "not exploitable in our current configuration, dependency is deprecated and will be removed in a later update" and move on. The 23305 bulletin tells you how to exclude the dependency via maven, that should work for 23302 as well.

In the future, please check ESAPI documentation to ensure that we haven't already addressed your CVE questions.

[kwwall]

@xeno6696 - Thanks for writing that up Matt. Saved me a lot of time.

@cwienands1 Actually, I should add that after more experimentation, the CVE-2021-35043 Antisamy vulnerability fixed in 1.6.5 doesn't seem exploitable under the standard ESAPI.properties configuration. I plan on writing that up in a new security bulletin when we do the next release. In the meantime, feel free to exclude 1.6.4 from the ESAPI dependency and include AntiSamy 1.6.5 directly.