I'm wondering if anyone has a solution for upgrading Python? Our Vulnerability scans are picking up a vulnerability with older versions of Python on a number or our mac machines. It appears Python 3.9.4 resolves this.
When I install the package for 3.9.4, it installs, but leaves the older Python Launcher folder in /Applications, and I assume some framework stuff elsewhere?
I'm not a python user and am afraid to remove that older folder out of fear(and also believe there is more to python than just that folder) of "breaking" something. We have a lot of dev users in our environment.
Thanks for any input on how to accomplish this upgrade.
hi @Moreal_Wilson - unfortunately i have not, and it is still an issue. To provide some more context:
Our IT Security team utilizes Qualys for Vulnerability detection
Qualys is detecting Python 3.8.2 as the vulnerable version in /usr/bin
I am reading this directory is the OS install directory for python
/usr/local/bin is the directory where any user installed versions of Python seem to be going.
I have no idea if removing/uninstalling Python from /usr/bin will "break" anything in the OS or not.
Thought I would follow up here. After doing some research and posing the question over in the macadmins slack I found that the version of python installed in /usr/bin/ is Apple's version that comes with xCode and the xCode CLI developer tools. A number of our devs utilize these, and also have utilized homebrew, which installs the xCode CLI dev tools as a pre req.
We opened a case with Qualys support and after fighting with them for awhile I got the following back today:
Greetings for the day..!
This is to inform you that for QID:375419, we have now modified the detection to now check the path:/usr/local/bin/python3 --version check, currently the QID is under the QA phase.
We will notify you as soon as the QID is released in production.
Technical Support Engineer
Qualys, Inc. | Continuous Security
So - if your vulnerability scanning solution is with Qualys, and the QID you're struggling with is 375419 then soon the detection logic should change and this will no longer be showing up it appears.
So I lied, Qualys did NOT update their detection and are still flagging /usr/bin/python3 (3.8.2) which is installed by the xCode CLI tools as vulnerable. We are still going back and forth with them, but I would encourage anyone who utilizes qualys for your vuln scans to also open a case with them if you are seeing the same. The more attention we can give to this the better, as I do not know of a way to patch the Apple version of python in /usr/bin.
hey @jon_verret - sorry i should have updated this thread. Unfortunately despite all of the evidence we presented to Qualys they would not budge and insisted this was an Apple/Python issue and remained steady in keeping the detection and in keeping their unhelpful solution. So, we ended up just removing/ignoring this particular vulnerability in our weekly scans.
Been trying to get answers from Qualys for nearly 2 months now and this is the email they sent me this morning:
"Thank you for the screenshot. I investigated the issue thoroughly and here’s my analysis:
Currently, the affected versions for QID 375419 are:
Python Versions 3.X up to 3.6.12
Python Versions 3.7.0 up to 3.7.9
Python Versions 3.8.0 up to 3.8.7
Python Versions 3.9.0 up to 3.9.1
From the screenshot you provided as well as the CSV report, we see the Python version of 3.8.2 which is also affected. The detection logic of QID 375419 will flag these versions and thus it is not a false positive in this case.
As we know that Python is open-source, it will be used by multiple vendors or platforms. The implementation of such libraries is in complete control of the vendor and it will differ from vendor to vendor. Here the python version (3.8.2) found on the host is vulnerable.We always follow the vendor advisory- Python for creating the detection logic.
Other vendors decide to support backporting versions as well.Thus, unless the official vendor(Python) releases any solution or backported version we cannot even change the detection of this QID.
You would have to possibly reach out to vendor Apple to see why this version cannot be uninstalled/modified or you can choose to ignore this vulnerability as Qualys will keep on flagging that QID if it detects one of those versions stated above for them being vulnerable.
I hope I could shed some light onto the issue.Please let me know should you have any questions/concerns regarding this QID and I'd be happy to take it forward."
So yeah, Qualys puts all blame on Apple and Python. Which is probably true, but I can't understand why Apple would be letting this sit around for so long. Do we all need to start bugging Apple support and if so what is the best way for that? For both of these Python QID's in /usr/bin/python3 we have ~160 for one and ~195 for the other. Has anyone had any luck resolving this yet?
Yeah true. That is definitely possible. I just wish we could find out definitively instead of having to guess. I would prefer not to exclude the QID's because if an actual vulnerable version was installed we need to know that. But with all of these detected right now it is a lot of work to know if it is one of these Xcode installs (that may or not be affected) or if it is definitely an affected one. A frustrating issue to be dealing with for sure.
It would be nice if there was a way to get Apple and Qualys to "talk" regarding this detection. However that seems to be impossible. I agree it would be nice to get a definitive answer, or at the very least an acceptable solution from Qualys, as they make the detection, and provide the results, and also a solution, but in our case at least the solution mentioned was not helpful at all, and if i remember correctly was tied to a Red Hat article.
I think it boils down to Xcode.app being installed and needing to be updated. Apple Enterprise Support was able to confirm that /usr/bin/python3 is installed as part of the Dev. Command Line Tools installed with Xcode.
I have a Smart Group based on an Extension Attribute to detect Python3 versions older than 3.8.9 and the membership ends up matching the devices being reported by Qualys. Those devices all have Xcode installed with versions prior to 13.2...
So, I'm going to be testing out the fix of simply asking users to update Xcode to at least that version and see if Qualys counts drop for this QID
I thought the same until I also discovered all of our HomeBrew users were also the ones popping up on this list. As you mentioned it's tied to the Apple Dev CLI Tools, which are also a pre req for HomeBrew installs. If you install the Apple Dev Tools CLI separate from xCode or HomeBrew, that install will still be flagged as vulnerable I found(at least as of the last time i put effort into this ~ 2-3 months ago).
I have experienced the same issues as described above. It has been very challenging to deal with.
This morning I did some testing and successfully upgraded to 10.4
Tried this workflow on a users machine. Did nothing. No idea how I updated my version or Python3 now.
I have a ticket open with Apple Enterprise Support who said /usr/bin/Python3 cannot be modified or deleted due to SIP. Fair enough.
Anyways..I 'thought' I had a solution, but I do not.
I recently ran in to the issue where the Qualys agent flagged the /usr/bin/python3 binary as a vulnerability.
The /usr/bin/python3 is part of the macOS install and it is only a stub, if you execute the /usr/bin/python3 binary it will ask you if the want to install Xcode/Command line tools.
If you have not installed Xcode on the machine Qualys will not flag it as a vulnerability, but if you have installed Xcode Qualys will flag it as a vulnerability, my guess is that when Qualys finds the /usr/bin/python3 binary it is able to run the command /usr/bin/python3 --version and it is considered vulnerable, if Apple has not updated the binary.
If you have not installed Xcode when the Qualys agent finds the /usr/bin/python3 binary it is unable to run /usr/bin/python3 --version command, because it is a stub and it is not considered vulnerable by the Qualys agent.
The next issue is you can not remediate the /usr/bin/python3 binary, because it is part of the system volume, which is SIP protected and starting with Big Sur the system volume is cryptographically signed (Signed System Volume).
The system volume is controlled by Apple and is theirs to update.
Now if you use the Python installer to install Python it will install to /usr/local/bin, which is not SIP protected and not part of the system volume and completely writable, so you can update the Python binary located there.