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

281–290 of 323 posts

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

#281

Post by gnufx »

ryukafalz wrote: post #121
arijun wrote: post #47

In the end I think the solution to these issues will be something like what's promised by the Bytecode Alliance[0]. The idea is you give each package its own WASM sandbox with granular control over its permissions. That solution also has the benefit of allowing you to call a package from any language from your language of choice. I highly recommnend reading their the article introducing the idea, its very convincing:…

I agree with this. They don’t mention this explicitly in the article, but it has a capability-based security model, which is something I think we desperately need in our OSes. (They do link to a paper about it that mentions this.) There are a few other such systems that look interesting; Agoric is working on one for JavaScript, Google has a kernel patch set that adds capability support to Linux, and Christopher Lemme…

Hear, hear on capability systems, but they seem of limited use confined to specific language implementations, as opposed to the whole system. I wonder what's the Google kernel patch, and how it compares with Capsicum. It's rather tragic to gain public awareness so long after KeyKOS et al...

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

#282

Post by thaumasiotes »

simias wrote: post #231
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."

cupsd asks for my admin credentials when I try to add a new printer, but admittedly that might not be the preferred way for people who run DEs like gnome or kde, I just tend to prefer a more barebones experience. But that's not really my point anyway, the point is that the cupsd process runs sandboxed with its own permissions while my text editor, my password manager and my web browser all share the same UID. If ther…

> the point is that the cupsd process runs sandboxed with its own permissions while my text editor, my password manager and my web browser all share the same UID. If there's a security vulnerability in Firefox and some attacker manages to hack my printer it's pretty bad. If they hack my password manager it's really, really bad.

That's true, but what it primarily suggests to me is that Firefox should be sandboxed. It seems possible that the main reason cupsd runs in a sandbox is that it's a source of attacks on you, not a target. (Why is it pretty bad if someone else hacks your printer?)

Firefox is a plentiful source of attacks on you. Your password manager isn't -- it already knows all your passwords; you trust it by necessity.

The password manager is a high-value target, and might (does) deserve extra protections for that reason, but the parallel in your example runs between cups and Firefox, not cups and the password manager.

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

#283

Post by cyphar »

dredmorbius wrote: post #227
fock wrote: post #179

Earlier quoted context omitted.

you could use some lightweight rootless containers: I wrapped bubblewrap in a small python-program parsing a YAML-configuration (which mirrors my hosts rootfs and provides "topical" homes: node, python, scientific stuff), but there is also something like toolbox: https://github.com/containers/toolbox/blob/master/README.md Note that you need to secure your X-Server also, especially when sharing your network-namespace.…

Containers (and virtualisation) are helpful but. not bulletproof. If your threat model is already malicious code with ill intent, you probably want higher grades of privsep / sandboxing. E.g., https://www.twistlock.com/labs-blog/escaping-docker-containe... https://www.exploit-db.com/exploits/46978 Full virtualisation does far better, though I believe there've been exploits there as well. Yes, from 2015: https://threa…

Docker has had it's fair share of breakouts because the default configuration doesn't use user namespaces (one of the most significant security isolation features in Linux) and runs as root. It's not indicative of how secure a properly set up container is -- I don't remember the last time there was an LXC or LXD breakout (which use user namespaces by default).

Source: I've found a fair few Docker breakouts. I also maintain runc, which is the lower-level container runtime component (where most of the breakouts are found).

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

#284

Post by _jal »

blaser-waffle wrote: post #115
y04nn wrote: post #31

Earlier quoted context omitted.

On freeBSD there is jails since year 2000.

Yeah I think about that each time my boss talks about how new and great docker and kubernetes are. It was old hat on FreeBSD 4.0 mate...

Jails, yes; k8, no.

But I do have to say, the more Canonical and Redhat attempt to "innovate", the more I appreciate FreeBSD.

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

#286

Post by 4bpp »

tanderson92 wrote: post #273
saagarjha wrote: post #221

Earlier quoted context omitted.

I would consider this to be a huge breach of privacy.

I wonder if the users who were affected by this malware think something similar.

As a general principle, Western legal systems don't let the victims determine the punishment for a misdeed. Are you suggesting this is not a good thing?

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

#287

Post by saalweachter »

geofft wrote: post #56
XorNot wrote: 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…

Without absolving us all of our responsibility to do better, to create systems that minimize the potential damage by bad actors, "I want to be able to download and execute random code off the internet and have it access my file system, my cameras, my network, my everything, but only in ways that don't hurt me", has always been kind of a pipe dream.

It's also kind of hilarious when the person downloading and executing random code off the internet isn't the naive user, the pointy haired boss, the stereotypical grandmother, the dumb tween, but the "sophisticated", computer-savvy, net-wise programmers.

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

#288

Post by eikenberry »

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.

But they are encrypted and so are of no use to anyone.

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

#289

Post by tialaramex »

geofft wrote: post #256
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…

> Then we could secure the agent (there's more work to be done here anyway) That's the problem, though. How do you secure the agent? How do you make sure that the program talking to the agent is doing something good and not evil with the request? Yes, there is some defense-in-depth advantage to making this change, but the thing you're trying to solve here is that you can pip install thing X and have thing X run ssh w…

You've decided upon a very broad and likely impossible to solve problem, whereas I'm focused on a narrower problem.

There is relatively little incentive to just "be evil". But much more incentive for certain specific intents that are evil, and so if we can make those trickier we get most of the benefit without solving the impossible problem.

This happens elsewhere in society. We put a bunch of effort into deterring car theft, but crooks could also steal mailboxes, or shrubs from your garden, or garbage. They mostly don't though because there's no incentive - in your city chances are you can find somebody who'll take a stolen car off your hands for cash, but good luck finding anybody who can pay you for a dozen stolen rose bushes.

Likewise I doubt that there's a healthy market for "Sometimes you might with no prior notice get to SSH into a target machine". Even the raw SSH private keys being stolen here are a pretty niche product, I think the actual authentication privilege itself, rather than the raw keys, is so much harder to exploit profitably that it won't sell.

That doesn't mean nobody would do this, but it makes it into a targeted attack. Think "organised gang break into one family home to kidnap a bank manager as part of a scheme to get into the vault" not "burglars break into homes across the city to steal jewellery". We don't fix the problem, but we do greatly mitigate the impact on most of the population.

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

#290

Post by tanderson92 »

4bpp wrote: post #286
tanderson92 wrote: post #273

Earlier quoted context omitted.

I wonder if the users who were affected by this malware think something similar.

As a general principle, Western legal systems don't let the victims determine the punishment for a misdeed. Are you suggesting this is not a good thing?

I wonder what gave you the idea that I was implying that.

Gitlab is of course free to disclose any information they like about those abusing their platform.

Post reply on HN