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

161–170 of 323 posts

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

#161

Post by fauigerzigerk »

simias wrote: post #126
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 peop…

I sort of agree, but I think that user interfaces need an underlying conceptual model that is familiar to users separately from the actual UI. Otherwise any purely presentational change implies arbitrary new rules that no one can remember.

One conceptual model that has worked to some degree on mobile platforms is the idea that programs not users have permissions.

But mobile platforms are overdoing it in a way that makes data centric work impractical.

I'm not quite sure how to overcome these issues, but I feel that making the distinction between permissions assigned to users vs permissions assigned to programs more explicit and more visible could take us a step further.

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

#163

Post by eitland »

vsareto wrote: post #57
ownagefool wrote: post #46

Earlier quoted context omitted.

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…

Monitoring isn't really a solution, it just lets you know you need to make new keys and gives you a point in time to figure out if they were used after being compromised

That's kind of like saying modern healthcare and vaccines isn't really a solution sinve someone will invariably catch the flu every time a new virus hits, isn't it?

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

#164

Post by xj9 »

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.

that's a problem with linux not taking container security seriously. there are other, more secure, container implementations in different kernels. containers are a good abstraction, but linux does them poorly.

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

#165

Post by tarsinge »

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…

> my keys, my photos, my docs

You listed it, the problem is personal data.

If an executable nuke my computer it’s a pain but if they don’t have access to my data it’s not that severe. For a long time we conflated the two, being hacked / getting a virus meant you got downtime, and you were screwed if you didn’t have backup, but it stopped here.

But really what changed in recent years in threat level is how much personal informations are in computers, and classic security models were not thought with that in mind. There is no « personal data » flag, just a permission it belongs to a user. It worked fine for executables and working documents, but personal data are a different thing.

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

#166

Post by AdmiralAsshat »

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

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.

One of the reasons I've stuck with Fedora is the fact that it does have SELinux turned on by default, and takes active steps to make sure that the policies are up to date. It can occasionally suck when something gets borked and one of my programs starts throwing SELinux errors after an update, but I think the security trade-off is worth it.

It becomes much more manageable when you go all-in on SELinux from the outset, rather than trying to bolt it on after-the-fact.

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

#167

Post by gruez »

f38zf5vdt wrote: post #91
gruez wrote: post #71

Earlier quoted context omitted.

I never understood the point of hardware tokens. If the machine it's plugged into it's compromised, the attacker can still use it to sign whatever they want. If the attacker has persistence on your machine, it's as good as stealing the key file. You're basically counting that you can discover the infection before the attacker can use it, or the attacker is unsophisticated so all they do is copy your .asc files (altho…

Yubikey owner. You have to physically insert the USB key and then interact with it (touch it) to do signing/auth/etc. If you hijacked the signing touch step, you'd notice that your signature wasn't generated by the touch and would know you're compromised. The key isn't plugged into the computer except when you're using it, and if you're in Qubes you have VM isolation for the USB ports. It narrows down the attack surf…

>Yubikey owner. You have to physically insert the USB key and then interact with it (touch it) to do signing/auth/etc. If you hijacked the signing touch step, you'd notice that your signature wasn't generated by the touch and would know you're compromised.

as mentioned by a sibling comment this can be worked around by social engineering. some ideas:

* simulating software/hardware/connection error, forcing the victim to retry. bonus points if you only start doing it after the victim installs an update to gpg

* in cases where you know the signature doesn't have to be valid, substitute a legitimate signing request with your payload, and returning a fake signature for the legitimate request. for instance, the you coax the victim into sending a signed gpg email. you know that nobody would be checking the signature except for you, so you detect that case and use that opportunity to sign your payload, and return a fake signature to the email program.

* my favorite: causing gpg to fail (thereby forcing the victim to retry) by injecting typos into his terminal when he's invoking gpg from the terminal

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

#168

Post by bredren »

jolmg wrote: post #159
jagged-chisel wrote: post #80

Earlier quoted context omitted.

I can only see this working where someone would copy and paste the package name. EDIT: another vector I saw mentioned in another comment: you pull in what appears to be a 'valid' dependency, and jeIlyfish is listed as a dependency of that package; looks legit so you proceed.

I suppose that could happen in a malicious tutorial or comment/post with the snippet, like in a StackOverflow answer.

The attacker would need to leave more footprints to do this, but yes. It is common for people to pipe up with "I wrote a thing that does this" and I imagine that results in people picking up odd packages.

I think an experienced programmer probably would be less likely to do this, but perhaps a junior programmer working on a system that no one wants to support anymore introduces a "bad" module.

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

#169

Post by marcus_holmes »

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…

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 risk is important. How much coding time is this saving? Would it, in fact, be quicker to just write that code yourself? Can you vendor it and cut out features you don't need? How many other people use this? Is it supported by its original maintainer? Does it have a deep-pocketed maintainer that could be an alternative target for legal claims?

Mostly, people don't do that and just "import antigravity" without wondering if there's a free lunch in there...

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

#170

Post by continuational »

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…

Why is it that we accept that any piece of code can just randomly reach into the file system and connect to any server?

Why isn't the file system an object you pass around instead?

Post reply on HN