For more context: this kind of work could fit nicely into the malware auditing system that was designed and implemented as part of the RFI that the blog author originally linked to[1].
Most of the infrastructure on the PyPI side is in place[2], but the current checks are mostly proofs of concept/exercises of the new APIs to ensure that they don't atrophy.
I've been in touch with folks from the Open Source Security Foundation [0] who is interested in making this a centralized service.
I'm a big believer that functions like this should be centralized under a foundation like that, and have really close connections to package manager maintainers so that we can work together towards solving the problem.
Something that just occurred to me - has anyone checked registries for owners with email addresses on either expired domains, or now available public domain addresses?
This seems like a ripe angle for package take-over.
> I still don’t like that it’s possible to run arbitary commands on a user’s system just by them pip installing a package.
Is there a build system out there that doesn't have this feature? Pip is both a package manager and build system since many packages are compiled at install time.
Looks like a great initiative and glad to hear this is getting attention.
The technique of observing syscalls has clear benefits. However might there be ways of evading this simply by setting up a some kind of delayed process so the syscall doesn't happen during the observation window or is only triggered rarely or on certain combinations that might not typically be tested (meaning it could still be caught in theory but the chances are much lower)?
1) The “observable window” is the entire installation time. If they make installs take forever, that’ll affect everyone which should raise alarms pretty quick.
2) The conditional execution is possible but the installation is done using a vanilla alpine container which will match many legitimate hosts too. And any fingerprinting activities that involve syscalls would be detected in the process.
All this to say, there’s always room to continue raising the bar!
Evil-me is thinking "So I need to check for the existence of super common but not core modules before I run my exploit code, so a vanilla environment never runs the code"...
That's the thing. If we're watching syscalls, we see these checks. These would be things like attempted file-reads. Would they be enough to set off alarms? Maybe, maybe not.
This is generally the cat/mouse game of malware detonation in general. There are attempts to make sandboxes appear realistic, but I'd argue that our use case is even simpler since running commands or making network connections during installation is not a normal thing. It might be benign, but it's abnormal enough to warrant investigation.
There will always be ways to try and get around the system, but I'm pretty firm that this will significantly raise the bar which is a Good Thing.
Usually in a containerization environment all the requirements are installed at the same time, which may or may not make that kind of introspection difficult.
On a dev machine though... diabolical. That might show up in a syscall, but perhaps not obviously enough that it sets off alarms.
If you're looking for a tl;dr you can find one on Twitter (with pictures!) [0]
This research was a blast to do, and I learned a ton. Happy to answer questions!
[0] https://twitter.com/jw_sec/status/1326908628411047937