4 ms·
Yes but the problem here is the obfuscation of the malware code loading. No need to trigger it in the setup.py process, as long as you have it in the lib, you c
by BiteCode_dev 4y ago
Yes but the problem here is the obfuscation of the malware code loading. No need to trigger it in the setup.py process, as long as you have it in the lib, you can always put a call in a .pth somewhere and run your malware as soon as any python is executed.
- zzzeek 4y agoit should be possible to test packages for that also. if you are testing setup.py to see that no network access or exec occurs, you could similarly run the python interpreter after install and ensure no network / exec() happens at that point either, assuming one has not imported the package. or just disallow unfamiliar .pth files from being installed altogether (outside of those generated by setuptools / etc. for normal execution).
- BiteCode_dev 4y agoGiven that every attempt to sandbox python failed, and that every system exposed to the public have been pwn, I assume this is a cat and mouse game we can't win. At best I suppose we could put in place checks to get low hanging fruits. But we are, after all, allowing a turing complete and highly dynamic language to execute. > or just disallow unfamiliar .pth files from being installed altogether That would kill the entire plugin ecosystem. Now, the next thing could be to have a permission system, requesting access to the network, fs, .pth, etc. It would not be a bad idea, given that we are, after all, installing things that are as powerful as apps. But it would be a gigantic effort, and users still would just accept without reading, like they do with apps.