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.
Unfortunately I don't have a really good answer for your problem, but I
thought it might be interesting that I looked into a very similar issue
lately, which is bundled jquery.
Plenty of applications bundle either jquery 1 or jquery 2, including
major applications like wordpress. They are unsupported, but jquery 3
introduces breaking changes and thus updates aren't easy, if you have a
vast plugin ecosystem like wordpress then it becomes almost impossible.
There are a couple of obscure CVEs in these versions that from my lay
understanding matter only in very specific circumstances. But they are
there and tools may flag them. I'm actually developing a security tool
myself that is somewhat affected by this (freewvs, optional -3
parameter ), where I don't really know how to handle this best.
An easy way out would be if jquery would provide security-only-updates
for their old branches, but they don't want to do that  and also it
seems one of the issues can't be fixed without breaking things.
David A. Wheeler
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. ...For the *badging* application this shouldn't be a big problem. I believe the criteria always talk about "exploitable" vulnerabilities of certain kinds as being unacceptable, not just vulnerabilities. (I think "vulnerability" always implies "exploitable" anyway, but saying things that way makes it clear.) Ignoring the distinction between vulnerabilities *in* the code & vulnerabilities in the code dependencies, let's look at criterion "static_analysis_fixed" as an example:
Notice that this criterion only focus on *exploitable* vulnerabilities. If a tool (like a static analysis tool) finds a purported vulnerability, but it's not actually exploitable, that does *NOT* count as a true (exploitable) vulnerability. Nor should it. No tool is a substitute for thinking; tools are good at warning people about *possible* problems.All medium and higher severity exploitable vulnerabilities discovered with static code analysis MUST be fixed in a timely way after they are confirmed.
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.)You should *definitely* do an official write-up. Publicly explain why it's *not* a problem in your case. I understand your skepticism, but it's still the right thing to do.
Looking at it from the other direction, it's perfectly reasonable for the SCA tools to flag ESAPI as vulnerable as long as they lack any other evidence. You need to provide the SCA suppliers with evidence that this should be squelched.
What probably needs to happen, long-term, is for there to be a standard way to report that "no, we're not vulnerable in this case". Then the SCA vendors can use that information in their tool. Here's a rough idea that I've thought about for 5 seconds (so no guarantees this is a *good* idea): There should be a standard directory name like "not-vulnerabilities". Its contents are files with the vulnerability id with a file format extension , e.g., CVE-2019-17571.md for a markdown file. That file includes a justification of WHY the default configuration (at least) is not vulnerable to that CVE, which may include inherited CVEs.
--- David A. Wheeler