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

211–220 of 323 posts

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

#211

Post by rob-olmos »

tus88 wrote: post #205

You know allowing people to upload libraries with highly conflicting names to existing ones is almost reckless. There is a bunch of stuff PyPi could do short of full curation that would make this much harder. A better solution is for languages to provide a kind of "module sandboxing" where modules need to declare the capabilities they need, and the runtime prevents them from accessing anything else. In this case, the…

Sandboxing in the language runtime is an interesting idea. I wonder if that could be offloaded to the OS/kernel instead so that every language doesn't have to reinvent the wheel. Eventually then hardware could handle it to reduce overhead.

Eg, declare parts of the compiled/interpreted code with specific privileges. Kind of like how memory regions can be NX.

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

#212

Post by Xylakant »

gruez wrote: post #142
Xylakant wrote: post #78

Earlier quoted context omitted.

Yubikeys for example can require a touch on the token to activate it. A dedicated attacker could still trick you into activating the token by waiting for you to do something where you'd need to activate it, but it significantly raises the bar. They also entirely prevent various compromises: * Theft or loss of the laptop does not mean loss of token. * Even if the token gets lost, cracking it will be hard. A dedicated…

>* Theft or loss of the laptop does not mean loss of token. Doesn't seem relevant when you probably have FDE enabled. >* Even if the token gets lost, cracking it will be hard. A dedicated attacker might be able to do it, but a 6 digit pin with 3 tries is hard to guess. Decapping and convincing a yubikey to reveal the secret key is likely possible, but nontrivial. To be fair, if you weren't using a token, and were jus…

> >* Theft or loss of the laptop does not mean loss of token. > Doesn't seem relevant when you probably have FDE enabled.

You still need to regard the key as compromised - it's no longer under your control and you have no idea what a potential attacker would try. Most FDE does not lock the disk when the computer goes to sleep, so the attacker can now try to break in via Firewire, ...

While with a physical token, as long as the token is in your possession, the key is entirely under your control (unless you have a backup on your computer, which kind of goes against the idea)

> Therefore, it's safe to assume that attackers interested in your key files are also sophisticated enough to perform the pivot.

Like they strictly did not even attempt in that case? This seems to be targeting python developers. Now, with a python developers ssh keyfile and gpg keyfile (if I manage to unlock it), I could do quite a bit of damage For example try it on github. It's trivial to associate an ssh key with a github acct - the info is public.

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

#213

Post by sitkack »

codedokode wrote: post #143
eythian wrote: post #131

Earlier quoted context omitted.

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

Yes because otherwise one user could configure a fake printer and see what others are printing. Although for one-user system this doesn't make much sense.

Maybe there should be a trust chain for everything.

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

#214

Post by icefog »

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…

OpenBSD has a really novel concept of using unveil and pledge to contain processes into restricted-service operating modes. And being OpenBSD, these security features are actually turned on by default for many binaries. See discussion in https://news.ycombinator.com/item?id=17277067

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

#215

Post by staticassertion »

Kalium wrote: post #209
staticassertion wrote: post #203

Earlier quoted context omitted.

Yeah I think it's totally insane. If your package requires a system dependency, like a binary, it should simply fail to install and let you know that you should go get that dependency. It should not, instead, require root privileges to add that to your system. Or, we should be providing virtualization like containers so that it can do 'root-y things' safely.

It sounds like you're describing snap packages. Is that accurate? That mostly works for whole applications. I'm not sure how to apply it to libraries for developers though. Especially ones that would get installed in userspace, like these python packages.

I'm not super familiar with snap, my weak understanding is that it makes for a very poor isolation boundary.

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

#217

Post by saagarjha »

icefog wrote: post #214
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…

OpenBSD has a really novel concept of using unveil and pledge to contain processes into restricted-service operating modes. And being OpenBSD, these security features are actually turned on by default for many binaries. See discussion in https://news.ycombinator.com/item?id=17277067

macOS has this already.

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

#218

Post by Kalium »

staticassertion wrote: post #215
Kalium wrote: post #209

Earlier quoted context omitted.

It sounds like you're describing snap packages. Is that accurate? That mostly works for whole applications. I'm not sure how to apply it to libraries for developers though. Especially ones that would get installed in userspace, like these python packages.

I'm not super familiar with snap, my weak understanding is that it makes for a very poor isolation boundary.

Yup, in large part because users expect things to work across the boundary.

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

#219

Post by staticassertion »

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…

Abusing the ssh-agent doesn't lead to the private key being stolen, which is a really nice difference.

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

#220

Post by staticassertion »

marcus_holmes wrote: post #169
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…

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…

Dependencies are great. Critical infrastructure with little to no security engineering effort is the problem.
Post reply on HN