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

231–240 of 323 posts

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

#231

Post by simias »

eythian wrote: post #131
simias wrote: post #126

Earlier quoted context omitted.

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

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

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

#232

Post by simias »

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.

Right, that's the problem IMO, the usual way processes are segregated on Linux harks back to the day of UNIX mainframes shared across dozens of users. It still makes some sense on servers where you want to isolate, say, the database from the web server from postfix from sshd but it's almost entirely inadequate for single-user desktop computers.

On my desktop root doesn't really matter, if my user gets compromised it's already game over. I have a lot more to lose if by browser gets backdoored that if my /etc/shadow gets leaked.

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

#233

Post by commandersaki »

maxander wrote: post #230

So they caught the guy using a cliched I-vs-l typosquatting scheme and lazily writing the malicious code in Python; we can presume they haven't caught the guy who took the trouble to put their malicious code in a pre-compiled C extension. Reminds me of the fraudulent scientific papers that get caught using really dumb fakes (e.g., microscopy pictures that are copies of one another re-zoomed and rotated); we catch the…

> For that matter, isn't there a reasonable systematic way to catch out typosquatters simply based on text analysis?

You could probably write one using Python & jellyfish.

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

#234

Post by JackRabbitSlim »

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…

MyPy requests permission to write data to the hard drive. MyPy writes malicious payload to a file and then execs it. MyPy never wrote a damn thing to a socket, netcat did through a bash/ash shell. (Windows named pipes may be a little trickier to work with but can yield similar results)

Sandboxing libraries specifically seems like a fools errand.

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

#235

Post by simias »

greggman2 wrote: post #174
simias wrote: post #126

Earlier quoted context omitted.

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

I agree it can be inconvenient but don't iOS and Android kind of show that for most users the experience can be just fine? For us devs we can still either open our systems or find better ways but I'd prefer the default to be more closed. I'd also prefer the default to be VM-ish. Right now I have 275 projects in my /home/me/src folder. Every one of them has at least a build process that executes code I have mostly not…

The problem with existing OSs is that if you don't make it the default and force everybody to adapt you end up with a half-assed solution with bad support that just gets in the way. I tried to use firejail to sandbox critical apps (mainly my browser, but also the closed source Spotify client for instance) but eventually gave up because it would just break too often.

On top of that the one app I'd like to sandbox more is obviously the web browser, but since nowadays web browsers are like a full OS on top of another it's really hard to finely grain permissions unless you want one profile per website. The browser needs access to the filesystem if you want to upload and download files, the graphics card if you want good performance and webgl, the sound API if you want audio, the ability to fullscreen if you want to be able to play games and videos that way, the printer if you want to print stuff, the USB stack if you want to use security tokens etc...

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

#236

Post by ris »

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 first step is to reject the fashionable "wild-west" style of package repositories and realize that maintained repositories came about for a reason. Then you can worry about rearchitecting your OS for sandboxes up the wazoo.

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

#237

Post by CGamesPlay »

commandersaki wrote: post #233
maxander wrote: post #230

So they caught the guy using a cliched I-vs-l typosquatting scheme and lazily writing the malicious code in Python; we can presume they haven't caught the guy who took the trouble to put their malicious code in a pre-compiled C extension. Reminds me of the fraudulent scientific papers that get caught using really dumb fakes (e.g., microscopy pictures that are copies of one another re-zoomed and rotated); we catch the…

> For that matter, isn't there a reasonable systematic way to catch out typosquatters simply based on text analysis? You could probably write one using Python & jellyfish.

I'm extremely disappointed to see that you didn't suggest using jeIlyfish instead.

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

#238

Post by riyakhanna1983 »

OrangeTux wrote: post #122

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

Im assuming that by "only" you mean there's limited impact. However, if the malicious package steals user keys, the harm can spread to the packages that may have received way more downloads.

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

#239

Post by icefog »

saagarjha wrote: post #217
icefog wrote: post #214

Earlier quoted context omitted.

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.

Does it? On OpenBSD, Chrome cannot read my ~/.ssh directory, can the same guarantee be made on Mac?

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

#240

Post by ddevault »

pfranz wrote: post #223
cozzyd wrote: post #103

Earlier quoted context omitted.

Indeed. Plus this whole "install the whole python ecosystem for each thing you want to use" is insane.

I'm a bit torn and often err on the side of installing into --user or virtualenv. What often happened is I would toy around with a project, install a few libraries, then abandon it. Months/years later I would hit an incompatibility and I wouldn't know which packages were necessary for things I use everyday and which were because of that abandoned package. Similarly, when revisiting that abandoned project I wouldn't k…

My solution for this problem is apk's virtual packages. I'll do something like this:

    apk add -t .myproject-deps py3-foobar py3-foobaz
This creates a fake ".myproject-deps" package which depends on py3-foobar and py3-foobaz, then I can just uninstall ".myproject-deps" later and it nukes the rest. `head /etc/apk/world` is generally sufficient to get a list of projects I've forgotten about whenever I feel like some spring cleaning.
Post reply on HN