Live data from Hacker News

Two malicious Python libraries caught stealing SSH and GPG keys

zdnet.com

191–200 of 323 posts

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

#191
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…

This is why I don't think this is an OS problem. I think it's a developer mindset problem. Dependencies are bad. Every single dependency in your code is a liability, a security loophole, a potential legal risk, and a time sink. Every dependency needs to be audited and evaluated, and all the changes on every update reviewed. Otherwise who knows what got injected into your code? Evaluating each dependency for potential…

I strongly disagree that this isn't an OS problem.

s/dependency/application/g in your comment. Dependencies are just applications that are controlled through code rather than via a mouse/keyboard. They're not special.

I run a minimal Arch setup at home for my development machine, partially for security/reliability reasons -- less software means fewer chances for something to go wrong. But this is a band-aide fix. A minimal Arch setup that forgoes modern niceties like a graphical file browser is not a general-purpose solution to software security.

When someone comes to me and says that an app is stealing their iOS contacts behind their back, my response isn't, "well, its your own fault for installing apps in the first place. Apps are bad." My response is to say that iOS apps shouldn't have access to contacts without explicit permission.

The same is true of language dependencies. Both users and developers need the ability to run untrusted code. The emphasis on "try your hardest not to install anything" is (very temporarily) good advice, but it's ultimately counterproductive and harmful if it distracts us from solving the root issues.

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

#192
post #56
post #24

Earlier quoted context omitted.

This is literally what SELinux does, and has been able to do for years. We don't need "default block lists" - we need solid SELinux policy in all distros.

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

If you are installing paramiko or ansible you know what you are doing. It should be end user conscious choice to give them access. You should not be prevented to give that access but also that access should not be granted without end user knowing it.

You don't want to instal "some library, from somewhere" to have automatically access to everything on your machine.

I also agree with all people that comment that it is solved problem in technical means. I someone installs random stuff it is like crossing street with closed eyes, you might not get hit by a car, but yeah chances are much higher then if you take your time and look around what you are doing.

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

#193

Earlier quoted context omitted.

That sounds like a boil the ocean solution. We're never going to get all developers to be perfect, and besides there are evil devs as well so the solution has to be elsewhere.

Well, where, exactly? The solution most people seem to be talking about is sandboxing imports off into containers (sandboxes, whatever - these will end up as containers) so that they can have their access to sensitive data and API's controlled. These aren't "code dependencies" any more, these are "runtime services". It implicitly conforms to "dependencies are bad" by forcing all dependencies to be external services.…

> And specifically granting access permissions to code has always worked before, right? I mean, people never just click "allow" all the time so they're not bothered by security dialogs, do they? Why are we talking about implementing such a proven-bad solution yet again?

To be clear, is your argument that it's too hard for us to teach people to avoid granting unnecessary permissions, but not too hard for us to teach users not to install any software in the first place?

Educating users about permissions is hard, convincing users not to download anything is impossible.

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

#194

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…

Just have package managers run as a separate user in a separate namespace? I don't get why we let packages do crazy shit on our system as a fully privileged user.

Look to browsers, imo. 'Extensions', which are very analogous to packages, have to package a manifest, users must explicitly ack the permissions, and they have restricted access to the system.

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

#195
post #172
post #95

Earlier quoted context omitted.

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…

> %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. I'm with you about requiring signatures, and you can get around the FUD about packages getting abandoned because of developers losing keys by implementing something like TUF[1] (because of delegations in the targets role), but I don't really see how you can…

I don't have any particular definitive solution in mind. Attestation is possible (e.g. https://developers.yubico.com/PGP/Attestation.html), but just telling people to do it right should go pretty far, especially if the packaging software doesn't cater to circumventing the policy.

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

#196

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…

You know you should not run as root and you should not install all kind of crap on your computer.

Every time you walk on the street you have to trust 1000s of strangers they are not going to murder you or rob you. You also know you should not go into dark alleys alone at night.

This is just how life works.

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

#197
post #50
post #12

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

Modern SSH versions only store hashes of domain names in the known_hosts file exactly for this reason.

I haven't personally seen that enabled by default.

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

#198

Earlier quoted context omitted.

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

> You get the same exact problem, but with the agent permissions rather than the actual keys. This is also importantly wrong in a subtle way. If evillib123 steals a SSH private key, that key isn't private any more and my only option is to revoke the key and make a new one. Nothing else works, they have the key and can authenticate as me as often as they like whenever they like until that key's access is revoked. But…

This is a good point. Agent still does not solve the "I thought I meant to do it, but I didn't really mean to" problem, but I agree that it does take a step towards minimizing the damage.

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

#199

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…

Just have package managers run as a separate user in a separate namespace? I don't get why we let packages do crazy shit on our system as a fully privileged user. Look to browsers, imo. 'Extensions', which are very analogous to packages, have to package a manifest, users must explicitly ack the permissions, and they have restricted access to the system.

Most packaging systems are designed with the expectation that they will be installing arbitrary things that can interact with one another in arbitrary ways that should not have to be defined in advance for a given package.

The result has been a very hands-off approach. Package management systems for user-land libraries, like pip and so on, are extra guilty of being hands-off. And who wants their dev tools telling them what they can and can't do?

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

#200
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…

This is why I don't think this is an OS problem. I think it's a developer mindset problem. Dependencies are bad. Every single dependency in your code is a liability, a security loophole, a potential legal risk, and a time sink. Every dependency needs to be audited and evaluated, and all the changes on every update reviewed. Otherwise who knows what got injected into your code? Evaluating each dependency for potential…

At the risk of sounding like someone who wants to spark a language fight (which I genuinely don't) this is why I love Go. The standard library is so good that I rarely need to bring in any third-party dependencies, and the few I do use are extremely well-known with many eyes on their code.
Post reply on HN