Need some advice addressing "unfixable" publicly known vulnerabilities

Kevin W. Wall
 

CII Badging community,

I just updated the ESAPI project on the CII Badges site to account for a newly discovered CVE. Specifically, I added this verbiage:

Most Software Compositional Analysis tools / services (e.g., OWASP Dependency Check, BlackDuck, SourceClear, etc.) also flag ESAPI as being vulnerable to CVE-2019-17571 because it uses log4j 1.2.17. However, the ESAPI development team has examined this CVE and the ESAPI source code and do not believe that this CVE is exploitable in the manner that ESAPI is using it because we do not use the affected vulnerable class nor any log4j 1.x class that invokes the vulnerable class. We have deprecated the use of log4j 1.x in ESAPI and changed the default logger to JUL, but we are unable to remove this dependency without potentially breaking client code. Therefore we intend to follow our ESAPI deprecation policy and keep this dependency (even though it is past end-of-support) until either 2 years or until the next ESAPI major release (which would be ESAPI 3.0). We do not fell this is an issue because SLF4J is also supported and can be used to provide similar functionality.

However, we are in a bit of a pickle really. The latest release, as well as all previous releases of ESAPI, used log4j 1.x as the default logger. As explained above, while we have recently made changes to deprecate this and replaced it with java.util.logging (JUL) as the default, there are thousands of clients out there who are still using ESAPI with log4j 1.x which unfortunately means it would not be prudent to break client applications by completely removing log4j 1 support. (We can also support log4j 2.x via SLF4J, which we also support but making a switch from log4j 1 to log4j 2 is not trivial and thus may not be an option for many of our users.)

Our problem is that because many Software Composition Analysis (SCA) tools and services now flag ESAPI as being vulnerable to CVE-2019-1757. Even though we believe strongly that ESAPI's use of log4j 1 does not expose our users to this vulnerability, that belief--even if released as some official statement (which we are considering) is unlikely to help all that much. For some more details about some of these concerns, please see https://groups.google.com/a/owasp.org/forum/#!topic/esapi-project-users/XxKBjj3HuSw. (And yes, I know I forgot to erase the SMTP headers of the original poster's email resulting in his privacy not being not maintained; I've already apologized to him.)

Anyhow, my concern--because I have observed it first-hand within my company--is that companies will no longer permit their projects to continue using ESAPI and migrate to something else, which is all well and good when their ESAPI dependencies are few and suitable replacements exist. (I even describe potential replacements here: https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Should_I_use_ESAPI_3F) But for some things in ESAPI there are not ready made replacements (e.g., ESAPI Validators, ESAPI safe logging) and for many others, their ESAPI use is extensive so migrating to something else would be expensive.

So I am looking for suggestions of what I can do to relieve the fears about "Using Components with Known Vulnerabilities" when it comes to ESAPI. The SCA subscription services carry a lot of weight within companies and the FUD factor often takes over especially when they are spending big bucks on those SCA services. I've seen it first-hand.

The dilemma we have is we can't (well, won't; it is simply not good policy if you are an SDK provider) just immediately remove support for a potentially / presumably vulnerable dependency when that will break applications of potentially thousands of clients. (And in an ironic an eat-your-own dogfood sort of way, ESAPI logging is an integral core component of ESAPI so you are using it whatever other ESAPI component / feature you are using.)

So as ESAPI developers, what are our options here? I could write-up an official security bulletin and describe how we've analyzed the CVE in question and don't believe it is exploitable the way that ESAPI uses it as well as suggesting how to use alternatives such as SLF4J with either log4j 2 or logback, etc. We could build a "kill switch" that could be set in the ESAPI.properties file which would flat out disallow ESAPI to use log4j 1.x (discussed in the Google Groups URL above). But I'm not sure any of those would be useful or helpful to the masses which is why I am coming to my security conscious comrades and hoping that one of you will think of something that I haven't. We do plan on addressing this in our next release notes and as you can see, have already mentioned it in our Google Groups ESAPI Users list.

So if you have some ideas, please let me hear them.

Thanks,
-kevin
--
Blog: http://off-the-wall-security.blogspot.com/    | Twitter: @KevinWWall
NSA: All your crypto bit are belong to us.

Join CII-badges@lists.coreinfrastructure.org to automatically receive all group messages.