Live data from Hacker News

PyPI: Python packets steal AWS keys from users

blog.sonatype.com

91–100 of 104 posts

Re: PyPI: Python packets steal AWS keys from users

#91

In Linux, is there a secure, but also convenient and user-friendly, way to prevent processes from having the same default level of access to the filesystem as the human user? I like Android's system of per-app uid/gid. But AFAIK it's not implemented by any mainstream Linux kernel or distro. There's AppArmor, but the last time I tried it, I came away with the opinion that it's not very convenient or user-friendly. Per…

As others have said, containerisation is what you want.

If you want something low level look at bubblewrap (brwap). Firejail is also another tool to do this, a bit higher level and with more features (maybe too many IMHO).

Re: PyPI: Python packets steal AWS keys from users

#92

Network access (outgoing) should be firewalled a lot more these days.. There’s almost no need to open an outgoing connection

Right. Have a DNS servers which only forwards request to trusted domains, and a transparent proxy which only allows traffic to those same domains.

This is not a new idea at all, but it's still a very good one.

Re: PyPI: Python packets steal AWS keys from users

#93

I've been building tooling to mitigate supply chain attacks like these. Packj [1] analyzes Python/NPM packages for risky code and attributes such as Network/File permissions, expired email domains, etc. Auditing hundreds of direct/transitive dependencies manually is impractical, but Packj can quickly point out access to sensitive files (e.g., SSH keys), spawning shell, data exfiltration, etc. We found a bunch of mali…

How do you make sure the dependencies the tool itself uses are sane to use?

By pinning versions, running Packj on deps and manual analysis :)

Re: PyPI: Python packets steal AWS keys from users

#94

I've been building tooling to mitigate supply chain attacks like these. Packj [1] analyzes Python/NPM packages for risky code and attributes such as Network/File permissions, expired email domains, etc. Auditing hundreds of direct/transitive dependencies manually is impractical, but Packj can quickly point out access to sensitive files (e.g., SSH keys), spawning shell, data exfiltration, etc. We found a bunch of mali…

Thanks, will take a look at this - would be lovely to add something of this nature to a CI pipeline.

We've created a Github action [1]. It pulls data from our backend service https://packj.dev that continuously scans packages. You will have to create a free account.

1. https://github.com/marketplace/actions/packj-dev-audit

Re: PyPI: Python packets steal AWS keys from users

#95
post #64
post #52

Earlier quoted context omitted.

Isn't this impossible as per the halting problem? It would be better to run the code in a sandbox and log all the syscalls it makes, similar to how Cuckoo's malware sandbox works.

Halting problem is only relevant if we are discussing a perfect 100% solution with no false-positives and false-negatives. In real-life it is not of much relevance. I haven't seen a practical case in my life where I would conclude that it is undecidable to say what a function does (happy to see some practical examples if someone has some). For a theoretical program that "uploads credentials iff a sub-program halts" y…

> undecidable to say what a function does (happy to see some practical examples if someone has some)

Any and all functions that involve templating/plugins/metaprogramming/etc (common in various web frameworks) that can effectively run arbitrary code and thus are undecidable. Also any function that does deserialization and thus will instantiate novel objects with their code, e.g. Python code that uses pickle will often be undecidable as its execution will depend on what exactly is unpickled.

Re: PyPI: Python packets steal AWS keys from users

#96

Earlier quoted context omitted.

Containerization is what you want. There are many containerization tools for Linux, Docker being the most popular, and systemd-nspawn being the most Linuxy, but a bit unknown.

I didn't know about systemd-nspawn — thanks for the suggestion. I already use Dockerized aliases for some CLI apps (e.g.: ffmpeg) but I didn't find the approach as convenient as I'd like. I've found docker mounts difficult to secure. I'd like to mount $HOME but exclude even read-only access to "$HOME/.ssh/", "$HOME/passwordsafe.pwsafe3" and a dozen other sensitive file patterns. Some kind of predefined "access profil…

I hacked up a bash script for running arbitrary command in docker container, mounting only PWD. It traces dynamic libraries through ldd and creates a new image for each unique command. I got it working for ffmpeg:

https://github.com/paskozdilar/dockerify

I might try to optimize it a little bit later, perhaps bind-mount dynamic libraries instead of creating a new image for each command.

Re: PyPI: Python packets steal AWS keys from users

#97
post #82

Earlier quoted context omitted.

Wow. So what you are saying is that someone with knowledge of a company’s internal private package dependencies would be able to hijack their build process by publishing a higher-numbered version of the same package to the public PyPi? And even if the build system explicitly references the package version number, part of the time the package would be taken from the public PyPi instead of the company’s own package ser…

Using hash checking mode: https://pip.pypa.io/en/stable/topics/secure-installs/#hash-c...

Straight from the horse's mouth! Thank you, I didn't know about this.

Re: PyPI: Python packets steal AWS keys from users

#98
post #7

I wonder if the target of loglib-modules and hkg-sol-utils is a specific company running its own internal PyPi server, or something like a scientific collaboration (which can be thousands of people and billions of dollars, especially in the drugs discovery domain). PIP is designed to treat all indexes as mirrors, rather than to specify the source of a package: So a higher package version of an internal package name w…

Wow. So what you are saying is that someone with knowledge of a company’s internal private package dependencies would be able to hijack their build process by publishing a higher-numbered version of the same package to the public PyPi? And even if the build system explicitly references the package version number, part of the time the package would be taken from the public PyPi instead of the company’s own package ser…

This is an attack vector which has been exploited in the past to great effect[1].

[1] https://arstechnica.com/information-technology/2021/02/suppl...

Re: PyPI: Python packets steal AWS keys from users

#99

In Linux, is there a secure, but also convenient and user-friendly, way to prevent processes from having the same default level of access to the filesystem as the human user? I like Android's system of per-app uid/gid. But AFAIK it's not implemented by any mainstream Linux kernel or distro. There's AppArmor, but the last time I tried it, I came away with the opinion that it's not very convenient or user-friendly. Per…

> In Linux, is there a secure, but also convenient and user-friendly, way to prevent processes from having the same default level of access to the filesystem as the human user?

SELinux, if it was easier to use!

Apparmor

Bubblewrap?

If anything the problem is that there are too many mechanisms and most users are familiar with none of them...

Re: PyPI: Python packets steal AWS keys from users

#100

In Linux, is there a secure, but also convenient and user-friendly, way to prevent processes from having the same default level of access to the filesystem as the human user? I like Android's system of per-app uid/gid. But AFAIK it's not implemented by any mainstream Linux kernel or distro. There's AppArmor, but the last time I tried it, I came away with the opinion that it's not very convenient or user-friendly. Per…

Containerization is what you want. There are many containerization tools for Linux, Docker being the most popular, and systemd-nspawn being the most Linuxy, but a bit unknown.

Containers don't contain.

You have to assume that any code running inside a container has broken outside of its mount namespace & can interact with anything running on the host. Only Linux's traditional mechanisms (credentials; capabilities; SELinux policy; others are available) are able to defend against this.

Post reply on HN