Tenable Python vulnerability

Hi Thomas,

If you’re on Commvault 11.28.63+, 11.32.4+, or any patch level of 11.34, Commserve no longer uses any copy of Python installed under Program Files. Are you running, or can you update to, any of these versions?

Per the versions mentioned by Carl, Commvault now deploys Python under:

C:\Program Files\Commvault\ContentStore\python

Although, in my lab I similarly have C:\Program Files\Python38 (and 39) even though there’s no version of Python available to uninstall from the Control Panel.

I just renamed the Python38/39 directories on the CS in my lab and will see if anything breaks.  I have a feeling they’re artifacts that were never cleaned up.  They don’t actually appear to have the full python binaries underneath them.

Thanks,
Scott
 

It would be good if there were a clean way to uninstall the existing Python packages installed by Commvault, rather than just deleting the directories. 

From what I have been able to find, if the original installer can be located within any of the Windows Package Caches, it should be as simple as running the installer with an /uninstall switch. 

If the original installer cannot be located, it looks like the details of the individual Python packages will need to be extracted from Registry, and manually uninstalled - but it appears that the order in which they’re uninstalled is important.

Yes, I would also like it if you could cleanly uninstall Python from the system. Unless there is a solution that does not endanger stability.

My CS environment runs fine without the C:\Program Files\Python* paths.

I cannot answer if there’s any way to clean them up other than deleting them.

Thanks,
Scott
 

I was able to locate the original Python 3.8.1 installation package (python-3.8.1-amd64.exe) within a “Package Cache” folder on our Standby CommServe. The installation package was run with the /uninstall switch, which appears to have cleanly uninstalled Python 3.8.1 - with the exception of some orphaned files within the C:\Program Files\Python38 folder, that needed to be manually deleted.

As the Python 3.8.1 installation package could not be located on the CommServe, it was copied from the Standby CommServe, and the above process was repeated successfully.

python-3.8.1-amd64.exe /uninstall

Presumably the above process could be repeated for the 3.6.x and 3.9.13 versions of Python, if the appropriate installation packages can be located / downloaded.

The problem with these Python installation lingering under Program Files is that you can't judge for 100% if Commvault is the only one using it. So, I can imaging this is why they do not uninstall automatically. As long as it only concerns backend components than you can make the call easily, but on clients you can't. So, it's good that they moved it now to their own installation path. 

In my experience, they should appear on the software list in Windows and be removable like any other. @Onno van den Berg  is right, that we never know if a customer has been using them outside of Commvault for their own scripting, so we do not remove them automatically.

Hello @Carl Manzi, 

Ok then I'll try to delete the affected version from the hard drive and check tomorrow whether the problem is solved afterwards.

This can help …  It is describe that after uninstallation we should delete the folder that can contain Codes created after installation.  And also remove any shortcuts that may still under the start Menu.

https://kb.commvault.com/article/67335