commvault.com commvault.com
Solved

jQuery Vulnerability Found on the WebConsole

J
Rank
Badge +1

Hi all,

 

A customer has recently brought this to our attention that within their environment there is an outdated version of the jQuery being utilised via their WebConsole. 

They are currently running 11.20.85 and the version of jQuery they are still using is 2.1.3 which has known vulnerabilities. I am aware of there being another topic open for a similar, if not same, issue.

https://community.commvault.com/topic/show?tid=988&fid=2

However, this does not look to have a promising resolve, is there a resolve to mitigate these vulnerabilities or force the webconsole to utilise a more updated version of the jQuery?

 

 

Kind regards,

 

Jonathan

 

 

icon

Best answer by Mike Struening RETIRED 29 July 2022, 15:56

View original

10 replies

Aplynx
Rank
Userlevel 6
Badge +13

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

Liam
J
Rank
Badge +1

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

Mike Struening RETIRED
Rank
Userlevel 7
Badge +23

@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.

https://www.linkedin.com/in/michael-struening
Mike Struening RETIRED
Rank
Userlevel 7
Badge +23

@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!

https://www.linkedin.com/in/michael-struening
Mike Struening RETIRED
Rank
Userlevel 7
Badge +23

Sharing closure from referenced case:

Finding Details:

These vulnerabilities were detected on the webconsole machine.

Vulnerable javascript library: DOMPurify
version: 2.0.12
script uri: https://cdr.jhahosted.com/webconsole/common/thirdPartyV2/purify.min.js?1651179091551

and

Vulnerable javascript library: jQuery
version: 2.1.3
script uri: https://cdr.jhahosted.com/webconsole/common/js/jquery.min.js?1651179091551

Solution:

Question thread was made to the dev team who mentioned that they don't have a fix for these. As the Webconsole is being merged into the Command center over FR28 and up. Currently a large majority of webconsole reports have been moved over to the Command center.

Download Center : Targeted for FR28
My Data, Computers: Targeted for FR30

This information was brought to the customer's attention but they've seen gone dark, archiving.

https://www.linkedin.com/in/michael-struening
Onno van den Berg
Rank
Userlevel 7
Badge +19

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. 

Mike Struening RETIRED
Rank
Userlevel 7
Badge +23

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.

https://www.linkedin.com/in/michael-struening
Mike Struening RETIRED
Rank
Userlevel 7
Badge +23

@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.

https://www.linkedin.com/in/michael-struening
Onno van den Berg
Rank
Userlevel 7
Badge +19

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.

 

Mike Struening RETIRED
Rank
Userlevel 7
Badge +23

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.

https://www.linkedin.com/in/michael-struening

Reply


Terms & ConditionsCookie settings