Re: Need some advice addressing "unfixable" publicly known vulnerabilities

David A. Wheeler

Kevin Wall:

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. ...
Our problem is that because many Software Composition Analysis (SCA) tools and services now flag ESAPI as being vulnerable to CVE-2019-1757.
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:
All medium and higher severity exploitable vulnerabilities discovered with static code analysis MUST be fixed in a timely way after they are confirmed.
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.

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!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.)
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 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.
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., 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

Join to automatically receive all group messages.