3 ms·

Worth exploring safeguard for some: The automatic import can be suppressed using Python interpreter’s -S option. This would also disable site import so not via

by 6thbit 7mo ago

Worth exploring safeguard for some: The automatic import can be suppressed using Python interpreter’s -S option. This would also disable site import so not viable generically for everyone without testing.

cpburns2009 7mo ago
The 1.82.7 exploit was executed on import. The 1.82.8 exploit used a pth file which is run at start up (module discovery basically).
zahlman 7mo ago
It's not really "automatic import", as described. The exploit is directly contained in the .pth file; Python allows arbitrary code to run from there, with some restrictions that are meant to enforce a bit of sanity for well-meaning users and which don't meaningfully mitigate the security risk. As described in https://docs.python.org/3/library/site.html https://docs.python.org/3/library/site.html : > Lines starting with import (followed by space or tab) are executed.... The primary intended purpose of executable lines is to make the corresponding module(s) importable (load 3rd-party import hooks, adjust PATH etc). So what malware can do is put something in a .pth file like import sys;exec("evil stringified payload") and all restrictions are trivially bypassed. It used to not even require whitespace after `import`, so you could even instead do something like import_=exec("evil stringified payload") In the described attack, the imports are actually used; the standard library `subprocess` is leveraged to exec the payload in a separate Python process. Which, since it uses the same Python environment, is also a fork bomb (well, not in the traditional sense; it doesn't grow exponentially, but will still cause a problem). .pth files have worked this way since 2.1 (comparing https://docs.python.org/2.1/lib/module-site.html https://docs.python.org/2.1/lib/module-site.html to https://docs.python.org/2.0/lib/module-site.html https://docs.python.org/2.0/lib/module-site.html). As far as I can tell there was no PEP for that change.

by 6thbit 7mo ago

cpburns2009 7mo ago

The 1.82.7 exploit was executed on import. The 1.82.8 exploit used a pth file which is run at start up (module discovery basically).

zahlman 7mo ago

It's not really "automatic import", as described. The exploit is directly contained in the .pth file; Python allows arbitrary code to run from there, with some restrictions that are meant to enforce a bit of sanity for well-meaning users and which don't meaningfully mitigate the security risk. As described in https://docs.python.org/3/library/site.html https://docs.python.org/3/library/site.html : > Lines starting with import (followed by space or tab) are executed.... The primary intended purpose of executable lines is to make the corresponding module(s) importable (load 3rd-party import hooks, adjust PATH etc). So what malware can do is put something in a .pth file like import sys;exec("evil stringified payload") and all restrictions are trivially bypassed. It used to not even require whitespace after `import`, so you could even instead do something like import_=exec("evil stringified payload") In the described attack, the imports are actually used; the standard library `subprocess` is leveraged to exec the payload in a separate Python process. Which, since it uses the same Python environment, is also a fork bomb (well, not in the traditional sense; it doesn't grow exponentially, but will still cause a problem). .pth files have worked this way since 2.1 (comparing https://docs.python.org/2.1/lib/module-site.html https://docs.python.org/2.1/lib/module-site.html to https://docs.python.org/2.0/lib/module-site.html https://docs.python.org/2.0/lib/module-site.html). As far as I can tell there was no PEP for that change.