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

121–130 of 323 posts

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

#121

Post by ryukafalz »

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 Lemmer Webber is working on a similar system on top of Racket called Spritely Goblins. I’m excited about all of them though, because it feels like this kind of security model is starting to gain public awareness!

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

#122

Post by OrangeTux »

At pypistats.org download numbers of the last half year can be found.

* python3-dateutil has 271 downloads from non-mirrors in last month[1]

* jeilifish has only 106 downloads from non-mirrors in last month[2]

[1]:https://pypistats.org/packages/python3-dateutil

[2]: https://pypistats.org/packages/jeilyfish

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

#123

Post by tialaramex »

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…

> 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 a FIDO device to get a key.

One of the obvious things the agent could do on a workstation is mention that your keys are being used. Imagine you run a job, which reaches out via Paramiko to fifteen servers, you see a brief notification saying the agent signed 15 logins for Paramiko. That makes sense. An hour later, reading the TPS reports, the agent notifies you again, Paramiko just signed another login. Huh? Now you're triggered to investigate what happened and why instead of it just silently happening and you read a press piece in a month about how a new version of Paramiko is off-siting your keys because bad guys broke into a GitHub repo or whatever.

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

#124

Post by f38zf5vdt »

Spivak wrote: post #117
SEJeff wrote: post #110

Earlier quoted context omitted.

An alternative solution is just sandboxing of user processes ala containers. Something kind of like what Qubes does: https://www.qubes-os.org/ With a bit of work, the tech behind that could be made to work reasonably well in a general purpose linux distribution like say Fedora.

Shoving everything into namespaces doesn't solve everything because at the end of the day those 'containers' are still regular 'ole processes running in the root namespace under UIDs that are valid in the root namespace.

Qubes instances are native virtualized via hardware-assisted virtualization, so there shouldn't be any ability for instances to access root UID processes unless the hardware virtualization solution's security fails (Intel's cache/branch prediction attacks).

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

#125

Post by steventhedev »

qxnqd wrote: post #76
mikorym wrote: post #4

> The first is "python3-dateutil," which imitated the popular "dateutil" library. The second is "jeIlyfish" (the first L is an I), which mimicked the "jellyfish" library.

I don't get it. Who would type "pip install jeilyfish" by mistake?

Put yourself in the attackers shoes. Your goal is to spread this to as many machines as possible. The best and easiest way to do that is to add your library as a transitive dependency. What better way to infect people than to get everyone who ran `pip install numpy`? As for getting it in, I'd push it to older projects as part of a "styling cleanup" PR because there's so much noise in the diff anyways. Imagine a PR to a project adding a transitive dependency for python3-dateutil. Most people would merge without looking twice, especially if you add some scary "this deprecates py2 support" to the PR.

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

#126

Post by simias »

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 people will start mashing the "allow" button indiscriminately when they're in a hurry and want the thing to Just Work. There's only one thing I know for sure how to do with SELinux without having to lookup a guide or manual, it's how to disable it.

Look at the modern Linux desktop for instance, you need admin privileges to configure a printer but your sensitive private files are just lying on your home directory with user privileges. That makes no sense.

This is not really a technical problem, that was solved when we invented the MMU, it's an UI problem.

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

#127

Post by swebs »

pnutjam wrote: post #86
frou_dh wrote: post #10

These two have been caught. How many haven't yet been caught? Traditional Unix file permissions are pretty much a joke for the way developer computers get used (one user - does everything). Real process sandboxing is needed.

Not everything needs to run as root.

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

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

#129

Post by swebs »

bhouston wrote: post #43
saurik wrote: post #39

Earlier quoted context omitted.

Ok macOS you can easily throw your SSH keys into the secure Keychain (not that I do this...).

It should be the default that they are protected though on all os. We should not automatically trust locally installed apps anymore. They should be sandboxed by default like on Android and they should ask for permissions as they need them. Windows and Linux need to get with the times. My dev env should be sandboxed like everything else. Git can have ssh permissions but not every random tool from pip or the ceasepool…

Snap packages on Linux do this already

https://ubuntu.com/blog/a-guide-to-snap-permissions-and-inte...

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

#130

Post by C14L »

ownagefool wrote: post #46
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.

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.
Post reply on HN