jQuery Vulnerability Found on the WebConsole

https://documentation.commvault.com/11.24/essential/146231_security_vulnerability_and_reporting.html#cv2021121-vulnerability-in-apache-log4j-logging-libraries-impacting-commvault-products

Hi @Aplynx ,

Thank you for the fast response. However, unless I am being blind (which has happened before) this does not advise anything regarding the jQuery EOL version 2.1.3 being used and how to mitigate this usage.

Kind Regards,

Jonathan

@JonathanF , looks like we have a case opened for another customer for a similar question.  I’ll follow that and update you here.

Conversely, if you want to put added weight behind it, create a support incident on your end and mention case 220609-457.

@JonathanF , adding more.  I spoke to the case owner who suggesting creating a case and adding your voice to the issue.  will help us getting a solution quicker.

Let me know once you do!

What does this mean for us customers @Mike Struening? Are we vulnerable? Do we have to accept that we might vulnerable? Please share the risk assessment that was done that resulted in this answer to accept it and to bring back the news that it will be addressed in a new version that wille be released in the near future. 

Unfortunately, that was the end of the case as it was abandoned.

I’m following up with the case owner to see if there were further/pending developments.

@Onno van den Berg , got this from dev:

That depends on the exact issue reported.

Automated security scanners tend to look only at library version numbers and CVE lists. Since not every function in a library is used by every application, most security audits report a lot of issues that are not actually exploitable vulnerabilities.

It usually makes sense to upgrade a library anyway, even if a security issue is not exploitable, since that provides a high degree of certainty for customers.

But for an old application like Web Console, where it might take just as long to upgrade its libraries as it would to rewrite the application, that strategy doesn't work.

If an audit provides some evidence that a security issue is both present and exploitable in Web Console, we will review it and probably try to mitigate that issue. However, it is no longer possible for us to routinely upgrade every library deployed with the Web Console that has a CVE reported against it.

I understand for this case! So to summarize: we looked at it and concluded it's not exploitable and/or in use? 

The approach itself regarding deprecated features/code is somewhat to be questioned, because you basically state that we'll wait for evidence that a customer, or even worse someone from the outside was was able to exploit a known vulnerability before we fix/upgrade the related component. Doesn't feel that ok to me, especially because we are talking about a product/solution that functions as the insurance.

 

Sort of, more so ‘for every library we utilize, upgrading them all at once without any priority is a bad idea’.

Keep in mind, we are looking to slowly get everything upgraded, but we need to prioritize, and evidence of a problem is a good measure to use.