5 ms·
It's still the same story : PyPI still doesn't have a way to automatically detect interactions with the network and the filesystems for the submitted packages.
by almet 4y ago
It's still the same story : PyPI still doesn't have a way to automatically detect interactions with the network and the filesystems for the submitted packages. It's a complex thing to do for sure, but that would be a welcome addition, I guess.
- woodruffw 4y agoPyPI still doesn't have this because no packaging ecosystem does. It's impossible to do in the general case if your packaging schema allows arbitrary code execution, which Python (and Ruby, and NPM, and Cargo, etc.) allow. The closest thing is pattern/AST matching on the package's source, but trivial obfuscation defeats that. There's also no requirement that a package on PyPI is even uploaded with source (binary wheel-only packages are perfectly acceptable).
- eigenvalue 4y agoThis seems eminently solvable though. Why can’t every package submission cause some minimal sandboxed docker image to install the package and call the various functions and methods and log all network and disk activity? If anything looks suspicious it would be denied and the submitter would have to appeal it, explaining why the submission is valid. The same applies for NPM and Cargo. I know there is a researcher out there who has retrieved and installed every single pip package to do an analysis, which is a good start. This seems like the kind of thing that wouldn’t even cost all that much, and big corporate users of python would stand to benefit.
- nodogoto 4y agoWell some calls absolutely should invoke network or disk activity, so you would additionally need to define what constitutes good and bad activity for each. Moreover unless the package is a collection of pure functions it would be easy to hide the malware trigger in state that won't be initialized properly by the automated method calls but would be in the standard usage of the package.
- woodruffw 4y agoFor one, because Docker is not a sandbox, and containers are not a strong security boundary[1]. What you really need here is a strongly isolated VM, at which point you're playing cat-and-mouse games with your target: their new incentive is to detect your (extremely detectable) VM, and your job is to make the VM look as "normal" as possible without actually making it behave normally (because this would mean getting exploited). That kind of work has a long and frustrating tail, and it's not particularly fruitful (relative to the other things packaging ecosystems can do to improve package security). > I know there is a researcher out there who has retrieved and installed every single pip package to do an analysis, which is a good start. You're probably talking about Moyix, who did indeed downloaded every package on PyPI[2], and unintentionally executed a bunch of arbitrary code on his local machine in the process. [1]: https://cloud.google.com/blog/products/gcp/exploring-container-security-an-overview https://cloud.google.com/blog/products/gcp/exploring-contain... [2]: https://moyix.blogspot.com/2022/09/someones-been-messing-with-my-subnormals.html https://moyix.blogspot.com/2022/09/someones-been-messing-wit...
- com2kid 4y ago> What you really need here is a strongly isolated VM, Simplify, don't use a VM. Create an isolated network, hook your sacrificial machine up to it, have it install the package. Remotely kill it (network controlled power switch if needed). The machine's hard drive should be hooked up through a network controlled switch of some type. After the sacrificial machine is powered down, reroute the HD so it is connected to a machine that does forensics. Now you have a clear "before" and "after" situation setup for analysis. The sacrificial machine's network activity can be monitored by way of whatever switch/router it uses to connect to the Internet.
- spenczar5 4y ago"no packaging ecosystem does." This is a little bit too strong, since packaging doesn't require arbitrary code execution. For example, Go doesn't permit arbitrary code execution during `go get`. Now - there have been bugs which permit code execution (like https://github.com/golang/go/issues/22125 https://github.com/golang/go/issues/22125) but they are treated as security vulnerabilities and bugs. Of course, you're right about Python.
- woodruffw 4y agoWhat I meant by that is that no packaging ecosystem (to my knowledge) runs arbitrary uploaded code to find network activity. Some may do simpler, static analyses, but outright execution for dynamic analysis purposes isn't something I'm aware of any ecosystem doing. Python, Ruby, et al. are in an even worse position than that baseline, since they have both arbitrary code in the package itself and arbitrary code in the package's definition. But the problem is a universal one!
- spenczar5 4y agoAh, yep, you're right about that as far as I know too.
- blibble 4y ago> It's impossible to do in the general case if your packaging schema allows arbitrary code execution Java's type system: ClassLoaders plus SecurityManager was impossible? that's literally how Java applets worked, enforced through the type system https://docstore.mik.ua/orelly/java-ent/security/ch03_01.htm https://docstore.mik.ua/orelly/java-ent/security/ch03_01.htm yes, SecurityManager was a poor implementation for many reasons, but it's definitely not "impossible" to sandbox downloaded code from the network while having it interact with other existing code, you can do it with typing alone
- almet 4y agoI'm not sure it's not do-able, actually. What about having an execution sandbox and a way to check the calls made during the execution of the install script for instance? I worked a few years back on something like this but it went nowhere, but I still believe it would be doable and useful. The only trace I found back is https://wiki.python.org/moin/Testing%20Infrastructure https://wiki.python.org/moin/Testing%20Infrastructure, which contains almost no info...
- photon12 4y agoSmart attackers are already/will add `sleep(SOME_NUMBER_LONGER_THAN_SCAN_SANDBOX_LIFETIME)` before anything that does FS or network access. Not to say that this wouldn't be a welcome addition, but the scanning needs to be understood in the context of the inherent limitations of large scale runtime behavior detection of packages when you have a fixed amount of hardware and time for running those scans.