Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Two malicious Python libraries caught stealing SSH and GPG keys

zdnet.com

Post reply on HN
Print view View original

131–140 of 323 posts

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

#131

Post by eythian »

simias wrote: post #126
greggman2 wrote: post #13

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…

The problem is convenience vs. security, and we all know that even knowledgeable users will often sacrifice the latter for the former. Technically on many OSs you already have dozens of ways to achieve what you're saying. You could spawn a VM, use a different user, use some container framework, use SELinux, etc... The problem is that usability is generally terrible. Or maybe not terrible but bad enough that many peop…

> Look at the modern Linux desktop for instance, you need admin privileges to configure a printer

Not for an amount of time that is firmly outside "modern."

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

#132

Post by ownagefool »

vsareto wrote: post #57
ownagefool wrote: post #46

Earlier quoted context omitted.

There's a fair amount of other solutions to this too. Things today: - Protective monitoring. If it's stealing your key, it's presumably sending it somewhere, so somebody alerting should be going off asking clients are calling something external. - Peer review. Maybe its about time we question whether we should actually be running so many random modules without actually vendoring and reading the code. - Subscribing to…

Monitoring isn't really a solution, it just lets you know you need to make new keys and gives you a point in time to figure out if they were used after being compromised

You're right monitoring doesn't stop your key from being stolen, but it might stop your key being used or for the vulnerability being used again.

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

#133

Post by yingw787 »

Does PyPI offer package notarization and make that observable in the lockfile or the installation logs? Or offer optimized SEO for notarized packages over those not notarized in package search? If that’s not there, and I don’t see it as part of the PyPA roadmap, it might be a good first step to take.

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

#136

Post by more-coffee »

mikepurvis wrote: post #116
geofft wrote: post #56

Earlier quoted context omitted.

"Solid SELinux policy" is really the hard part there. When I pip install paramiko, I do, in fact, want it to have access to my SSH keys. When I pip install ansible, I want ansible to be able to shell out to OpenSSH to use my keys. If I write custom Python code that calls gpg, I want that custom code to be able to load libraries that I've pip installed without the gpg subprocess being blocked from loading my keys. If…

One nice thing about a virtualenv is that you get a copy of the Python interpreter in there, so it is in fact a separate executable running, for the purposes of hanging the policies off of.

Depending on the platform, virtualenv defaults to creating a symlink to the Python executable. You can override it with --copies, but then you have a new problem: updating the interpreter in all virtualenvs when a new Python release comes out.

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

#137

Post by fwip »

htns wrote: post #95
greggman2 wrote: post #13

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…

Qubes OS already exists! It's been perfectly usable for more than a decade now. It can't be recommended enough: https://www.qubes-os.org/ Sadly "modern security awareness" doesn't seem to really amount to anything, and existing solutions go unused. %90 of this "malware library" problem too would have been avoided if package repositories just required all packages to be signed with keys on hardware dongles. Ruby and p…

I don't think that's a good solution.

A) it adds cost to what was previously free for many people

B) it does nothing to deter bad actors

C) many software packages would be abandoned because their dongle was lost or destroyed

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

#138

Post by MadWombat »

tialaramex wrote: post #123
geofft wrote: post #56

Earlier quoted context omitted.

"Solid SELinux policy" is really the hard part there. When I pip install paramiko, I do, in fact, want it to have access to my SSH keys. When I pip install ansible, I want ansible to be able to shell out to OpenSSH to use my keys. If I write custom Python code that calls gpg, I want that custom code to be able to load libraries that I've pip installed without the gpg subprocess being blocked from loading my keys. If…

> When I pip install paramiko, I do, in fact, want it to have access to my SSH keys Do you? Wouldn't it be better if Paramiko was obliged to access your keys via the agent? Then we could secure the agent (there's more work to be done here anyway) and also it fixes problems where Paramiko wants to do something that the agent could facilitate (and so works with plain ssh) but Paramiko doesn't know about yet, like using…

> Wouldn't it be better if Paramiko was obliged to access your keys via the agent?

That's just kicking the can down the road. You get the same exact problem, but with the agent permissions rather than the actual keys.

The problem is "I installed paramiko and I know what it does and I want it to access my SSH credentials, but I don't want evillib123 to access my SSH credentials even though I have installed it as well and I think I know what it does, but I am mistaken" and the distinction between the two cases above is in the intent and judging intent is hard.

> One of the obvious things the agent could do on a workstation is mention that your keys are being used

This has been tried many times. Windows UAC is one of the more ubiquitous and notorious examples. If everything starts sending you notifications you stop paying attention to them. That is what happened to UAC, it would notify users about important things, software installs, system setting changes, admin accesses etc. but it was doing it too much and most people would just click through without actually reading what the notification is about. And the reason it was doing it too much is because it cannot judge intent. It cannot tell the difference between me installing an application deliberately and me installing an application because I was tricked into it somehow.

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

#139

Post by ownagefool »

C14L wrote: post #130
ownagefool wrote: post #46

Earlier quoted context omitted.

There's a fair amount of other solutions to this too. Things today: - Protective monitoring. If it's stealing your key, it's presumably sending it somewhere, so somebody alerting should be going off asking clients are calling something external. - Peer review. Maybe its about time we question whether we should actually be running so many random modules without actually vendoring and reading the code. - Subscribing to…

I like the idea to solve this on the software side. Be it by peer reviews or by some sort of social network, similar to GitHub, but for security reviews of software. Then you could decide to only install libraries that have a certain number of "good" points on the reviewer network, for example.

We're already crowd souring this when you run things like npm audit, and github stars, docker downloads, etc.

The problem is a tragedy of the commons in where we expect everyone else to do this for us and nobody does. This is why we need to rely on our own developers to actually do the reviewing, and why we have the monitoring to identify when that fails.

The more ways you attack the problem, the less likely you're going to be completely owned by a failure. Obviously sticking to a small number of generally trusted popular packages will likely make it easier to establish trust than using 1500 of them.

Obviously all this allies to other layers, such as Linux, your cloud provider, your hardware, your CI/CD, your secrets manager.

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

#140

Post by jmstfv »

Another insidious exploit is to hijack the maintainer's package manager account and push the code directly there, bypassing the repository altogether. It doesn't rely on you installing a new package since the hijacked package in question is already a dependency of yours.

I got into a habit of checking both the package manager and the project's repository before updating any given dependency.

https://news.ycombinator.com/item?id=20377136

Post reply on HN