skip to Main Content

This question is directly connected to my last question, however tackles a different topic so I am opening a new one.

As mentioned there I am getting an error relating to a missing SSL cert. The error does not appear when the script is started from Terminal, using PyCharm or running from VSCode, but without the debugger. Only when the script is run with the debugger, the exception is thrown.

After debugging a while I have found that the reason for the problem is the environment variable os.environ['SSL_CERT_FILE'] which in this case leads to a non-existing C:\Users\MYUSER~1\AppData\Local\Temp\_MEI97082\certifi\cacert.pem

  1. Starting the script without the debugger or in PyCharm, this variable is not set (debugging the imported minio package showed me that the result of certifi.where() is used if the variable is empty.
  2. With the debugger on, it is set before any of my script is executed (import os and print out all environment variables in the first line)
  3. If I manually delete the variable with del os.environ['SSL_CERT_FILE'] the rest of the script works fine, but the variable is again set in the next run
  4. I am using python 3.11, MiniConda and Windows 10, Visual Studio Code is updated to the last version 1.77.0
  5. Setting the environment variable in launch.json with "env": {"SSL_CERT_FILE": "foo"} will override the varible as expected, however as soon as I remove this line the wrong value appears again.
  6. The part "..\_MEI247522\..." in the value will change from run to run
  7. Creating a completely new folder/project the problem still exists
  8. I also tested with another python environment (Python 3.9.7) and the problem still is the same.
  9. From user @Horsing’s suggestion: I have also removed all the code from my script, except for import os. As soon as os is imported and I can inspect os.environ, the environment variable is already set.

I honestly have no idea, where and why this variable is set when the script is run in the debugger and what triggers it. Any help would be much appreciated, since manually deleting it is not really a good solution!

Addition
Here is the Python Debug Console output in VS Code (with my username changed). For this I have removed the launch.json and started the debugger with Python:File

complete code:

import os
print(os.environ.get('SSL_CERT_FILE'))

console output:

(minio) PS C:UsersmyuserDocumentssourcePythonminio-project>  c:; cd 'c:UsersmyuserDocumentssourcePythonminio-project'; & 'C:UsersmyuserMiniconda3envsminiopython.exe' 'c:Usersmyuser.vscodeextensionsms-python.python-2023.6.0pythonFileslibpythondebugpyadapter/../..debugpylauncher' '60007' '--' 'C:UsersmyuserDocumentssourcePythonminio-projectmain.py' 
C:UsersMYUSER~1AppDataLocalTemp_MEI223042certificacert.pem

Again, the printed path does not exist on my computer

2

Answers


  1. Chosen as BEST ANSWER

    I have not found the reason this problem appeared, but after a complete clean re-intall (which neatly got me into this issue :-/ ) the problem is gone and the environment variable is not set anymore.

    I will post this issue as a bug on the conda repo since it seems to be an their issue, at least as far as I can tell.


  2. The path set in the SSL_CERT_FILE variable is suspiciously similar to what you would get when running a python application packaged by PyInstaller for windows.

    Since the _MEI directory name is changing with each run, part of the code between the last place you can consistently not see SSL_CERT_FILE set and your python test program must be unpacking a PyInstaller package, running some code, then continuing on with executing the python interpreter with the modified environment.

    This behavior could be due to malware that has inserted itself somewhere in the code path when you execute python.exe inside the minio conda environment. This could be in a library loaded by the debugger, or for some reason only the debugging path activates that particular malware. Maybe the malware is looking for web browser behavior and the debugpy satisfies those requirements (it does open a newtwork socket).

    Why would the malware modify SSL_CERT_PATH? Probably to perform a man-in-the-middle attack against ssl/https traffic, stealing passwords, banking credentials, session keys, etc. Why is the file not actually present? Maybe the malware crashed, maybe it failed when attaching to a process that isn’t actually a web browser, or the specific software it’s targeting.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search