Steven Stewart-Gallus added the comment: I agree that this is not a likely scenario but I can think of one mildly plausible scenario. Suppose some web server runs a Python CGI script but has a bug that leaks a file descriptor into the script. The web server sandboxes the Python CGI script a little bit with resource limits so the leaked file descriptor is higher than the script's file descriptor maximum. The Python CGI script then runs a sandboxed (perhaps it's run as a different user) utility and leaks the file descriptor again (because the descriptor is above the resource limits). This utility is somehow exploited by an attacker over the internet by being fed bad input. Because of the doubly leaked file descriptor the attacker could possibly break out of a chroot or start bad input through a sensitive file descriptor. Anyways, the bug should be fixed regardless.
Thanks for correcting me on the location of the fd closing code. Some observations. Strangely, there seems to be a _close_fds method in the Python subprocess module that is not used anywhere. Either it should be removed or fixed similarly. For understandability if it is fixed it should simply delegate to the C code. The bug I mentioned earlier about concurrently modifing the fd dir and reading from it occurs in _close_open_fd_range_safe which is a genuine security issue (although I don't know if it's ver likely to happen in practise). Because _close_open_fd_range_safe can't allocate memory the code there will be pretty ugly but oh well. There doesn't seem to be any point to caching max_fd in a variable on module load. Why not just use sysconf every time it is needed? Is there some need for really fast performance? Does sysconf allocate memory or something? Anyways, the code should be refactored to not use max_fd on the platforms that support that. Thank you for your thoughts. Also, should I keep discussion of some of the bugs I observed here or raise them in other issues so they don't get lost? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21618> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
