Update Python

bmack99
Contributor III

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.

29 REPLIES 29

Moreal_Wilson
New Contributor II

We are having the same situation.  Have you found any resolution?

bmack99
Contributor III

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.

trevor_w
New Contributor II

We are in the same exact scenario and use Qualys as well. I have no idea how to get it updated and don't know what can or can't be removed. 

user-lrRSgzkxgs
New Contributor

Hi all,

We are facing the same issue. Talking with DEV team to test if block and after that delete the file process cause any problem.

bmack99
Contributor III

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:

Hello Brian
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.

Regards,
Priyanka Athavale
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.

jon_verret
New Contributor III

Hey Brian, I'm seeing the same thing in our env.  Did you ever get an update from Qualys or find another solution to resolving the issue?

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.

jon_verret
New Contributor III

No problem! Thanks for the update! We may need to have the same discussion internally.

trevor_w
New Contributor II

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.
[1] https://success.qualys.com/discussions/s/article/000006230

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?

You ran into the exact same frustrating brick wall we hit with Qualys. Sorry. 😞 We ended up just excluding those detections from our scans as Apple doesn't seem to acknowledge a vulnerability(and in fact there may NOT be one with the "in house" version of Python they are using.

trevor_w
New Contributor II

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.

jon_verret
New Contributor III

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



trevor_w
New Contributor II

Thanks for the info. Keep us posted on if that fixes it and if so if you just simply ran a command to update Xcode or if you did it differently. 

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

rqomsiya
Contributor III

Hi all,

Curious if anyone got any traction with this?

pueo
Contributor II

Hi All, 
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

  • On a fresh macOS12.3.1 installed
  • first checked for Python3 - not installed as expected.
  • Installed XCode - Python 3.8.9 installed.
  • Installed Python 3.10.4 from python.org site
    • As expected, the path was /usr/local/bin/python3
    • I did not create a symlink to /usr/bin/
  • Run Software Update which listed Command Line Tools beta 4 Xcode and Command Line Tools for Xcode.
  • Installed both.
  • Reboot
  • Checked version of Python - 3.10.4

    I'm guessing the updated Developer CLT updates Apple's Python.
  • Still going to put in a ticket with Apple Enterprise Support.

pueo
Contributor II

**EDIT**...I lied.

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.

dbrundage
New Contributor II

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.  

Kevin_K
New Contributor II

This is an old thread and I'm apologize if there is a faux pas for resurrecting one. I have this same issue and have run into nearly identical responses from Qualys. They say its vulnarability and want proof that it's been removed before they will stop flagging it.

 

I've gone a bit further than others in this thread in regards to the symbolic links by trying to undo them but that doesn't have any effect on whether or not Qualys flags that /usr/bin/python3 folder. Not all of the units I have being flagged even have xcode installed so I'm at a loss as to what triggered it to be flagged in the first place. I'm even now getting a machine that has Python 3.9.1 installed and is being captured by Qualys as a problem. 

 

Is there any update to this or a way to force an update? I had hoped that taking one of the machines from Mojave (dont ask) to Monterey would resolve it but that had no effect either. 

 

Could installing a version of xcode and then upgrading it and then remove it be a possible solution? 

Kevin_K
New Contributor II

Meant to post the code I was using to dink with the symlinks. Its a massive cludge and didnt break my machine during testing so....

 

#!/bin/bash


rm -rf /Library/Frameworks/Python.framework/Versions/3.8.2
rm -rf /Library/Frameworks/Python.framework/Versions/3.7.3
rm -rf "/Applications/Python 3.8.2"
rm -rf "/Applications/Python 3.7.3"
cd /usr/local/bin/
ls -l /usr/local/bin | grep '../Library/Frameworks/Python.framework/Versions/3.8.2' | awk '{print $9}' | tr -d @ | xargs rm
ls -l /usr/local/bin | grep '../Library/Frameworks/Python.framework/Versions/3.7.3' | awk '{print $9}' | tr -d @ | xargs rm

this will not be much help, but we gave up on qualys. they were completely unwilling to look outside the box so to speak, and it was a waste of too much time for us, so we just started excluding those 
CVE's from our detection scans.

Kevin_K
New Contributor II

That is likely what I am going to have to do here. I've already been in talk with our Security team about this mess after banging my head against the wall for a few months off and on trying to figure out a solution and fighting with the vendors over this. ¯\_(ツ)_/¯

You also need to note that a user can have xcode cli tools installed with the vulnerable version, but if they install their own python and symlink /usr/bin/python3 to that location, Qualys also won't pick it up b/c the check Qualys is using for /usr/bin/python3 --version will redirect to the python3 version they have installed and that version may not be vulnerable. 

pueo
Contributor II

I submitted a ticket to Apple Enterprise support who informed me it was not a vulnerable application in the eyes if Apple, yet as mentioned on this thread Qualys sees the baked in version on Python installed via CLI or Xcode as a vulnerability. I think Homebrew too.

I could only defer the Vulnerabilities until Jan in the hope Ventura and Xcode 14.x update the version of python Apple use. 

**Update**

I am running Ventura and Xcode 14.1. The Python version located at /usr/bin/python is 3.9.6 which is an update from the 3.8 I had on a few months ago running Monterey.  
How long until Qualys sees 3.9.6 as a Vul?

Kevin_K
New Contributor II

3.9.6 started showing up just a few days ago, unfortunately. Thankfully we don't have many of these and if Apple sees them as not an issue then it appears there is not much we can do. This is just one of those weird things that will sit in back of my head and always be a 'what if' scenario everytime I hear about a data breach. Oh well, who needs hair? :D

pueo
Contributor II

Bummer, thanks for update @Kevin_K   Guess I will be chatting to my boss and Security about this.  Co-workers believe Apple and Qualys should get on a call and discuss it. I still think eventually they will butt heads and nothing will come of it.

pueo
Contributor II

Looking at our Qualys console the suggested solution is to update to Python 3.9.5 and above.  Looks like Qualys will eventually get to 3.9.6 and I will start to see Qualys Vulnerabilities again.  

This issue will never get permanently resolved.


An exert from Qualys Detection Summary:

Python 3.9.0 /usr/bin/python3

Affected Versions:
Python Versions 3.8.0 up to 3.8.11 and 3.9.0 up to 3.9.4

Solution:

Customers are advised to install python version 3.9.5 or newer.