2 ms·
First of all: I'm glad that more people are trying to tackle this problem! That being said, I'm not sure if I would encourage this approach: this conflates mod
by woodruffw 4y ago
First of all: I'm glad that more people are trying to tackle this problem!
That being said, I'm not sure if I would encourage this approach: this conflates modules (a property of the Python language) with dependencies (a thing that maps roughly to packages/distributions, which are a property of Python packaging). The two actually aren't that connected: there's no guaranteed 1-1 (or even 1-N) mapping between a dependency's package name and its importable modules, meaning that knowledge of a malicious package doesn't imply that you can derive how that package's module(s) get imported at runtime.
More perniciously: module names aren't static. It's pretty easy to construct a dynamic module object, or to rename (or alias) an existing module object to avoid this kind of detection.
Finally: walking a project's import tree isn't safe in the general case! Lots of packages have side effects when imported, and malicious dependencies definitely take advantage of that ability. Running this tool might find a malicious import by virtue of actually running malicious code, which isn't ideal.
If your goal is to detect malicious API patterns at runtime (which is effectively what you're doing when you walk the package import tree), I think runtime audit hooks[1] are probably a better fit. Those also aren't foolproof either, but they'll probably be more reliable (and don't require as much context awareness to determine maliciousness).
[1]: https://peps.python.org/pep-0578/ https://peps.python.org/pep-0578/
- maweki 4y ago> It's pretty easy [...] to avoid this kind of detection. And by rice's theorem, it is generally undecidable whether there are hidden modules loaded. Static (or in this case maybe not so static) analysis of arbitrary code will never lead to 100% safety. You'll always need some static restrictions on what code you're even allowed to write.
- janalsncm 4y agoComing at this from a naive perspective, do we care if a module is provably, definitely imported? I think for supply chain attacks it should be sufficient to say this module might be imported and deserves attention. I assume Rice’s theorem would also say that even though malicious code is imported it might not run the malicious bits today or on this machine [1]. But that doesn’t mean I’m ok with having it there. [1] https://en.m.wikipedia.org/wiki/Stuxnet https://en.m.wikipedia.org/wiki/Stuxnet
- maweki 4y agoIt's undecidable whether there even is an import of stuff. It's every non-trivial property that's undecidable. So the question whether a certain line is reached is as undecidable as the question what values can arguments have at that line. So it's undecidable whether a dynamic import statement is reached and what its import argument will be. And even if the value is static, then it's undecidable whether the content of the imported module has been just changed.