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

181–190 of 323 posts

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

#181

Post by tialaramex »

MadWombat wrote: post #138
tialaramex wrote: post #123

Earlier quoted context omitted.

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

UAC interrupts you, which is bad. UAC thinks that a thing happening is so important you need to acknowledge it. Everybody's going to learn to click past.

I'm talking about notifications not interruptions. At most a toast message, much more likely just a small indicator lights up. Not a big deal - when you'd expect it.

Think about the turn indicator on the dashboard of your car. When you indicate one way or the other a lamp illuminates, on and off, sympathetic to (and in older models directly run by the same relays as) the external turn lamps. But it doesn't ask you to confirm. "Are you really turning Left? Yes/ No" and since you're expecting it you hardly notice. But, imagine you're on the highway and suddenly that lamp illuminates for no apparent reason. That's weird right? You might be too busy to do anything about it immediately, but you'd now be concerned that perhaps there's a problem. Good!

That's what I'm talking about. Yes, out of a million users whose key got abused, maybe 90% of them weren't looking at the screen when it happened and 90% of those left were too busy or didn't understand why it was strange, and 90% of those who noticed never actually investigated and 90% those who investigated give up without notifying anyone about this weird phenomenon... you've still got a hundred users complaining about the problem.

It's not a solution, but it's a warning system.

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

#182

Post by megous »

avian wrote: post #50
megous wrote: 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.

Hmm, you're right, but HashKnownHosts in openssh defaults to no, still.

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

#184

Post by wglb »

jolmg wrote: post #162
wglb wrote: post #111

This shows the inadequacy of thinking “open source makes all bugs shallow”.

On the contrary, this wouldn't even need to be hidden if it was closed source. It was caught because it's open source.

Possibly, but some of the solutions proposed, e.g., monitoring of network activity, would work either way.

It concerns me that one of these sat out there for a year.

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

#185

Post by tialaramex »

MadWombat wrote: post #138
tialaramex wrote: post #123

Earlier quoted context omitted.

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

> 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 if they only have permission to get the agent to do operations their ability to authenticate is limited by the agent. If they lose access to the agent they can't authenticate any more. That would happen if I uninstall their malware, or if the agent locks access of its own accord (e.g. it's common to auto-lock after suspending a machine or locking the screen) or if the machine is just switched off altogether.

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

#186

Post by otachack »

swebs wrote: post #127
pnutjam wrote: post #86

Earlier quoted context omitted.

Not everything needs to run as root.

Ok, but your private keys are stored in your home directory. No root access required.

For sure, but does applying a password on pub-priv key creation encrypt it? Haven't tried it myself yet but may later when I'm back at my computer.

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

#187

Post by notatoad »

asdkhadsj wrote: post #83
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…

> 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. Would Python permissions even be enough though? All it takes is one legitimate Python application wanting your Photos (lets say some Python photo manager app you wrote) and now all Python libraries get access. Unfortunately, I think Apple's direction may…

Wasn't this the promise of containers? "python" should have access to the whole system that it is run on, but instead of running random python scripts you download from the internet on your base system that has all your personal data in it, you run it in a container that only has the specific files that the script needs access to.

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

#188

Post by GordonS »

School-Cotton wrote: post #146
whack wrote: post #61

Earlier quoted context omitted.

When I first realized that any and all code that I execute, has read/write permissions to most of my filesystem, it blew my mind. The OS grants every process its own unique virtual-memory-space, specifically to prevent malicious/accidental interference with other processes. It seems like the file-system really should operate on a similar principle as well. Every application should run in a sandboxed environment by de…

This is already possible in Linux with mount namespaces, and used by (for example) systemd to block access to /home by services if so configured by the user.

I wonder if there is a Linux distro out there that works like the OP wanted out-of-the-box, with userland processes sandboxes by default, and providing a slick interface to grant access to areas of the filesystem when wanted?

There are so many distros with little differentiation - I'd think something like this would be quite unique (unless it already exists, and I don't know it!)

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

#189

Post by GordonS »

stan_rogers wrote: post #89
vsareto wrote: post #37

Earlier quoted context omitted.

Alert fatigue -> user accepts everything

See Windows Vista for reference.

This was my first thought too!

It was also my first thought after I recently upgraded MacOS, and was bombarded with multiple permission dialogs whenever I did anything.

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

#190

Post by marcus_holmes »

greggman2 wrote: post #175
marcus_holmes wrote: post #169

Earlier quoted context omitted.

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…

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. But it doesn't allow you to actually import known-good dependencies from trusted sources.

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?

Post reply on HN