Live data from Hacker News

Two malicious Python libraries caught stealing SSH and GPG keys

zdnet.com

31–40 of 323 posts

Re: Two malicious Python libraries caught stealing SSH and GPG keys

#31
post #23

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 pr…

Maybe the future is in fully sandboxed/containerized apps, where each action outside of sandbox/container is confirmed by the user.

On freeBSD there is jails since year 2000.

Re: Two malicious Python libraries caught stealing SSH and GPG keys

#32

Earlier quoted context omitted.

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…

yubikeys can store GPG keys and emulate SSH keys via gpg-agent. More exciting: OpenSSL recently added full U2F/Fido support, but it might take a bit until that lands in all distros https://www.undeadly.org/cgi?action=article;sid=201911150648...

yubikeys can store GPG keys and emulate SSH keys via gpg-agent.

Indeed. Same for gnuk keys. I currently use a gnuk key (Nitrokey Start) with Ed25519 and have GPG set up as the SSH agent for SSH. Though I hope to switch to a YubiKey soon, so that I don't need a separate key for U2F/Fido2.

Re: Two malicious Python libraries caught stealing SSH and GPG keys

#34
post #23

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 pr…

Maybe the future is in fully sandboxed/containerized apps, where each action outside of sandbox/container is confirmed by the user.

When Docker was first introduced this is exactly the niche I thought it was going to fill. After I elbows deep into it I saw that wasn't the case.

I still think something like it could evolve to fill that role.

Re: Two malicious Python libraries caught stealing SSH and GPG keys

#35

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 pr…

I suspect the solution is a combination of selinux (apparmor?) and curated code repositories. I don't think sandboxing alone is a solution as it doesn't alleviate concerns with zero days.

Re: Two malicious Python libraries caught stealing SSH and GPG keys

#36
post #9

What's the best information source for me to follow to keep up to date on these kinds of library vulnerabilities? I would make a feed of the homepages for all the libraries I know I use, but that won't help me with the libraries I use without knowing.

I saw a recorded conference talk where they mentioned Snyk as a way to keep your eye on package vulns, but have never used it myself

Re: Two malicious Python libraries caught stealing SSH and GPG keys

#37
post #23

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 pr…

Maybe the future is in fully sandboxed/containerized apps, where each action outside of sandbox/container is confirmed by the user.

Alert fatigue -> user accepts everything

Re: Two malicious Python libraries caught stealing SSH and GPG keys

#38

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 pr…

SandFS could be used for lightweight custom sandboxing $HOME dir. It uses eBPF to let you insert custom checks. Check https://lwn.net/Articles/803890/

Re: Two malicious Python libraries caught stealing SSH and GPG keys

#39

Maybe ash keys and got keys need to be protected from access by anything local unless given permission? Right now they are just files sitting there that can be read by any standard user process right?

Ok macOS you can easily throw your SSH keys into the secure Keychain (not that I do this...).

Re: Two malicious Python libraries caught stealing SSH and GPG keys

#40
"pip" has a usability problem. It should do a lot more at preventing this kind of thing. When using pip, it's not easy to tell information like the release date, how many versions have been released, and so on.

Since such info is available from PyPI API, I wrote my own "pypisearch" script to sort by latest release date and include number of releases to weed out packages that seem useful but are old or rarely released. I should probably integrate PGP signing info too into it.

Post reply on HN