On 15/04/2019 23.17, Steve Dower wrote:
On 15Apr2019 1344, Christian Heimes wrote:
(memory dump before I go to bed)
Steve Grubb from Red Hat security pointed me to some interesting things . For instance there is some work on a new O_MAYEXEC flag for open(). Steve came to similar conclusions like we, e.g. streaming code from stdin is insecure.
Thanks for the pointer! Using this for open_code() by default on platforms that support it might be a good opportunity in the future. But I'm glad I'm not the only one who thinks this is the right approach :)
Here is the original patch on LWN with some links to presentations:
The approach has one downside: The current user must have DAC executable permission for a file in order to open a file with O_MAYEXEC. That means we have to +x all Python files and PYC files, not just the files that are designed as entry points.
I think it would be also beneficial to have auditing events for the import system to track when sys.path or import loaders are changed.
Already in there (kind of... the "import" events include the contents of the sys properties that are about to be used to resolve it - since these are plain-old lists, and can be easily reassigned, passing them through here allows you to add a check if you really want it but otherwise not pay the cost of replacing the sys module with a special implementation and its attributes with special lists).
Yeah, it's complicated :/
Steve Grubb mentioned remote importers or hacks like mem_fd + dlopen() from /proc/self/fd as attack vectors. Mitigations and audit systems like IMA Appraisal only work properly if code has to hit the disk first. If an attacker or user can perform the equivalent of PROT_EXEC | PROT_WRITE, then IMA won't be able to 'see' the malicious code.
https://www.tutorialspoint.com/How-to-use-remote-python-modules https://github.com/operatorequals/httpimport https://0x00sec.org/t/pure-python-in-memory-so-loading-without-shm/6453 https://github.com/nullbites/SnakeEater/blob/master/SnakeEater2.py