Alarming given that pypi is treated as trusted by many I think (even if it shouldn't)
What is trusted then, the Anaconda base repo?
Two malicious Python libraries caught stealing SSH and GPG keys
11–20 of 323 posts
Re: Two malicious Python libraries caught stealing SSH and GPG keys
#12Anyone here not encrypting their private keys?
Also known_hosts file is a double edged sword. It's pretty sensitive in combination with a private key.
Re: Two malicious Python libraries caught stealing SSH and GPG keys
#13I don't know what the solution is but it feels like this is a much bigger issue and we need some rethinking of how OSes work by default. Apple has taken some steps it seems the last 2 MacOS updates where they block access to certain folders for lots of executables until the user specifically gives that permission. Unfortunately for things like python the permission is granted to the Terminal app so once given, all programs running under the terminal inherit the permissions.
Microsoft has started adding short life VMs. No idea if that's good. Both MS and Apple offer their App stores with more locked down experiences though I'm sad they conflate app security and app markets.
Basically anytime I run any software, everytime I run "make" or "npm install" or "pip install" or download a game on Steam etc I'm having to trust 1000s of strangers they aren't downloading my keys, my photos, my docs, etc...
I think you should be in control of your machine but IMO it's time to default to locked down instead of defaulting to open.
Re: Two malicious Python libraries caught stealing SSH and GPG keys
#14I get the python3-dateutil because you might think it's an updated version of the standard library. But how does jellyfish with a different char for L work? Someone would need to copy and paste it. But if they go to pypi, it won't have many installs. Unless they started writing tutorials with: "okay now just pip install X"
If I had to guess, I'd say that the JeIlyfish package is just here to wrap the malicious code since JeIlyfish is a dependancy of the compromised python3-dateutil package.
Re: Two malicious Python libraries caught stealing SSH and GPG keys
#15I don't know what the solution is but it feels like this is a much bigger issue and we need some rethinking of how OSes work by default. Apple has taken some steps it seems the last 2 MacOS updates where they block access to certain folders for lots of executables until the user specifically gives that permission. Unfortunately for things like python the permission is granted to the Terminal app so once given, all pr…
For this particular case: if you have GnuPG or SSH private keys, do not store them on-disk. Use a hardware token, such as a gnuk token, or a token with a secure element if you also want resistance against physical key exfiltration. A gnuk-based hardware token can be had in a nice format for under 30 Euro [1] or you could buy a STM32F103-based microcontroller for a few bucks and flash gnuk [2] if you like DIY. If you are a company, invest the 50 Euro in hardware tokens for your employees, one compromised SSH private key means that all the machines that use the public key are suspect.
I don't know what the solution is but it feels like this is a much bigger issue and we need some rethinking of how OSes work by default. Apple has taken some steps it seems the last 2 MacOS updates where they block access to certain folders for lots of executables until the user specifically gives that permission. Unfortunately for things like python the permission is granted to the Terminal app so once given, all programs running under the terminal inherit the permissions.
I fully agree. It seems that the UNIX model is not very compatible with the macOS permission system, but one could imagine defining multiple types of shell sessions, each with its own set of permissions.
[1] https://www.nitrokey.com/ [2] https://salsa.debian.org/gnuk-team/gnuk/gnuk
Re: Two malicious Python libraries caught stealing SSH and GPG keys
#16I get the python3-dateutil because you might think it's an updated version of the standard library. But how does jellyfish with a different char for L work? Someone would need to copy and paste it. But if they go to pypi, it won't have many installs. Unless they started writing tutorials with: "okay now just pip install X"
The python3-dateutil listed jeilyfish as a dependency - so I'm guessing that upon installing the fake dateutil, the user would see something like "installing dependency - jeIlyfish" - which, depending on your font, may, at the very least, cause a person to google "python3 what is jellyfish" arriving at a concise description of what jellyfish is from pypi.
Then dateutil calls the code in jeilyfish.
Re: Two malicious Python libraries caught stealing SSH and GPG keys
#17I get the python3-dateutil because you might think it's an updated version of the standard library. But how does jellyfish with a different char for L work? Someone would need to copy and paste it. But if they go to pypi, it won't have many installs. Unless they started writing tutorials with: "okay now just pip install X"
Just an idea: in autocomplete scenarios, jeIlyfish comes alphabetically before jellyfish, while looking like it. That could hijack an install. I don't know if and where autocomplete can be used with PIP, though.
Re: Two malicious Python libraries caught stealing SSH and GPG keys
#18I have been working on a Node.js library (very much work in progress and progressing slowly due to lack of time) that integrates libseccomp to be used programmatically inside Node.js whether at library or application level. For me at the moment it's kind of an experimental idea as it can be quite tricky to get everything right and in order without the kernel killing the process by mistake, but at least I think for some of the cases in the category that this issue is in, it will help mitigate it. I believe libseccomp already has official bindings for Python, as well as third party bindings for other languages, but this kind of work has been very successful in OpenBSD with pledge and I think it has been overlooked in dynamic programming languages and Linux in general.
Re: Two malicious Python libraries caught stealing SSH and GPG keys
#19Would sticking to the OS upstream package manager be a safer option compared to installing from pypi directly?
How often does something like this happen with packages in the CentOS, epel, or Debian repositories?
Re: Two malicious Python libraries caught stealing SSH and GPG keys
#20Terrifying but understandable. We need better ways to stop this but I'm not sure how...
In the meantime, store your private keys on a security device like a YubiKey. I use it simultaneously for all signing, encrypting, and authenticating (SSH as well as PAM to my workstations).
Be sure to set a strong PIN on the device. And have a backup!