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

201–210 of 323 posts

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

#201

Post by hatchnyc »

staticassertion wrote: post #194
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…

Just have package managers run as a separate user in a separate namespace? I don't get why we let packages do crazy shit on our system as a fully privileged user. Look to browsers, imo. 'Extensions', which are very analogous to packages, have to package a manifest, users must explicitly ack the permissions, and they have restricted access to the system.

Yeah but not just package manager. As a developer or build machine you are just the first potential target and potentially not even the most attractive one. If you've got a dependency on malicious package that is getting embedded into your code there's near limitless potential downstream harms waiting after the code is deployed.

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

#202

Post by MetalGuru »

gdevenyi wrote: post #150
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.

In science this is pretty important so we can control versions and reproduce a result again as well.

There are other, more efficient ways of handling dependency version conflicts than having an isolated env where each module is downloaded specifically for that env. For example, it doesn't make sense that if I have two virtual env's that ,use the exact same module (and version), it's downloaded and stored twice on my machine.

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

#203

Post by staticassertion »

Kalium wrote: post #199
staticassertion wrote: post #194

Earlier quoted context omitted.

Just have package managers run as a separate user in a separate namespace? I don't get why we let packages do crazy shit on our system as a fully privileged user. Look to browsers, imo. 'Extensions', which are very analogous to packages, have to package a manifest, users must explicitly ack the permissions, and they have restricted access to the system.

Most packaging systems are designed with the expectation that they will be installing arbitrary things that can interact with one another in arbitrary ways that should not have to be defined in advance for a given package. The result has been a very hands-off approach. Package management systems for user-land libraries, like pip and so on, are extra guilty of being hands-off. And who wants their dev tools telling the…

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.

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

#204

Post by staticassertion »

hatchnyc wrote: post #201
staticassertion wrote: post #194

Earlier quoted context omitted.

Just have package managers run as a separate user in a separate namespace? I don't get why we let packages do crazy shit on our system as a fully privileged user. Look to browsers, imo. 'Extensions', which are very analogous to packages, have to package a manifest, users must explicitly ack the permissions, and they have restricted access to the system.

Yeah but not just package manager. As a developer or build machine you are just the first potential target and potentially not even the most attractive one. If you've got a dependency on malicious package that is getting embedded into your code there's near limitless potential downstream harms waiting after the code is deployed.

There's a few different threat models, and different mitigations.

We have attackers who:

a) Want to run code on package installation

b) Want to run code on application execution

Restricting packages on installation helps with (a)

I disagree that developers are not attractive targets. If I were to target a typical tech company I would absolutely go for a developer. I'd wait for them to SSH to production, hijack their connection, and start moving around. That's a hell of a lot better than if I attack HR and have to start moving laterally in a corporate environment to escalate.

As for backdooring production services or applications, ala (b), it's a more complex and bespoke problem to solve I think. I think package managers themselves are not suited to solve this problem and it is up to the OS to restrict programs more by default, like mobile OS's/ Browsers do.

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

#205

Post by tus88 »

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 module would have needed to request the ability to make an outgoing TCP/IP connection - and that request should raise red flags for a date parsing utility.

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

#206

Post by WorldMaker »

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…

> Microsoft has started adding short life VMs. No idea if that's good.

The lightweight sandbox VMs seem to be pretty useful so far. It's still so new that I've not seen it used outside of blog posts yet, but that's the nature of cutting edge features only "just" released. (It was released with 1903 in May, which was delayed several months and a lot of businesses still are hesitant to install it.)

Windows 10 has had Controlled Folder Access (aka Ransomware Protection) available as an option for a while as well, which acts like Apple's system of forcing apps to need additional permissions to user directories. It's not quite as fine-grained as Apple's yet, and it is certainly not on by default.

(I turned it on for interesting paranoia reasons on my gaming desktop, and it's been fascinating to watch what gets blocked. Though my paranoia led me to adding Steam folders to the Controlled Folders list, which has especially made it a permissions whack-a-mole because Game Developers are children and games access random folders all the time, use five EXEs where one probably should have been enough, use random EXEs in TEMP folders to call EXEs in Steam folders, games not installed by Steam sometimes try to access Steam folders, NVidia wants to touch everything, etc.)

> Both MS and Apple offer their App stores with more locked down experiences though I'm sad they conflate app security and app markets.

Windows 10 has had sideloading on by default for years now, and supports Win32 apps inside APPX/MSIX. Win32 apps by default aren't nearly as sandboxed sadly (because it is hard to guarantee Win32 apps work as expected when sandboxed), but some sandboxing is better than none. The biggest issue seems a lot less to do with "app market" (you don't have to publish to the Microsoft Store, and MSIX even supports auto-updating for sideloaded apps vaguely "ClickOnce-style") and a lot more to do with "please rebuild your installer to something more modern", which is a hurdle a lot of developers don't want to overcome. (Because installers are terrible and once one is built who wants to rebuild it. Because MSIX support for Windows 7 is still "Beta" with the April end-of-support for Windows 7 looming over everything, and some Enterprises clutching their Windows 7 purses as the new XP...) Who wants extra app security when it means a lot of development effort to repackage your app? (Even if it can be semi-automated from your existing installer.)

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

#208

Post by Xylakant »

jlgaddis wrote: post #118
Xylakant wrote: post #26

Earlier quoted context omitted.

yubikeys can store GPG keys and emulate SSH keys via gpg-agent. More exciting: OpenSSL recently added full U2F/Fido support, but it might take a bit until that lands in all distros https://www.undeadly.org/cgi?action=article;sid=201911150648...

> OpenSSL I know what you meant to type but, for the benefit of everyone else here, he meant OpenSSH . (Normally I wouldn't comment just to correct a typo as the intention is usually obvious but this is a bit different.)

You're obviously absolutely correct. Thanks for the correction.

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

#209

Post by Kalium »

staticassertion wrote: post #203
Kalium wrote: post #199

Earlier quoted context omitted.

Most packaging systems are designed with the expectation that they will be installing arbitrary things that can interact with one another in arbitrary ways that should not have to be defined in advance for a given package. The result has been a very hands-off approach. Package management systems for user-land libraries, like pip and so on, are extra guilty of being hands-off. And who wants their dev tools telling the…

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.

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

#210

Post by hipnopotam »

MetalGuru wrote: post #202
gdevenyi wrote: post #150

Earlier quoted context omitted.

In science this is pretty important so we can control versions and reproduce a result again as well.

There are other, more efficient ways of handling dependency version conflicts than having an isolated env where each module is downloaded specifically for that env. For example, it doesn't make sense that if I have two virtual env's that ,use the exact same module (and version), it's downloaded and stored twice on my machine.

That's one of the issues that conda (https://docs.conda.io/en/latest/) solves by design. When using conda environments you get hard links whenever possible. Improvements to venv, making it built-in module, and projects designed to simplify dependencies made conda less attractive in comparison but it's still a solid way to have Python. Still, it doesn't really solve fundamental issue with Python packages you mentioned, unfortunately.
Post reply on HN