Bug #61020 [Com]: Security risk from find usage recommendation

Edit report at https://bugs.php.net/bug.php?id=61020&edit=1 ID: 61020 Comment by: chortos at inbox dot lv Reported by: ondrej@php.net Summary: Security risk from find usage recommendation Status: Open Type: Bug Package: *Configuration Issues PHP Version: 5.4.0RC7 Block user comment: N Private report: N New Comment: find on OS X does support -execdir. Previous Comments: ------------------------------------------------------------------------ [2012-02-09 01:13:40] aharvey@php.net One problem with all of the options here is that they're a fair way from POSIX compliant -- fuser on OS X doesn't support -s, for instance, nor does find support -execdir. Solaris find doesn't even support -delete or -print0. Obviously this is less of an issue in Debian. :) Given the (pretty severe) restrictions if we want to cover all of the non- Windows platforms PHP runs on, do we even want to recommend a one-liner in php.ini? Maybe it would be better to come up with a short, portable shell script and include it in the session reference in the manual and link to that. ------------------------------------------------------------------------ [2012-02-09 00:41:43] ondrej@php.net s/most error-prone/least error-prone/ ------------------------------------------------------------------------ [2012-02-09 00:31:44] ondrej@php.net And if you cannot use find with -delete or -execdir at least do: find /path/to/sessions -mindepth 1 -maxdepth 1 -cmin +24 -execdir rm "{}" \; ------------------------------------------------------------------------ [2012-02-09 00:29:10] ondrej@php.net Description: ------------ ; NOTE: If you are using the subdirectory option for storing session files [...] ; find /path/to/sessions -cmin +24 | xargs rm because it is prone to '\n' attack. You can see the security considerations of GNU find. Much better would be: find /path/to/sessions -cmin +24 -delete or at least find /path/to/sessions -cmin +24 -execdir rm "{}" \; (GNU find) The most error-prone way is something we cooked up in Debian: find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -ignore_readdir_race -cmin +24 ! -execdir fuser -s {} 2>/dev/null \; -delete which depends on fuser at least version 22.15 (which has removed fork() call which was able to swamp up whole system with zombies). The fuser call checks if the session file is still in use, because the script was deleting still active sessions opened 24+ mins ago. Test script: --------------- Race condition for -exec rm {} \;: while true; do mkdir /var/lib/php5/blah touch /var/lib/php5/blah/passwd rmdir /var/lib/php5/blah ln -s /etc /var/lib/php5/blah done xargs attack: ondrej@howl:/tmp/php_sess$ touch bar ondrej@howl:/tmp/php_sess$ touch -t 201201010000 "$(echo -e 'foo\nbar')" ondrej@howl:/tmp/php_sess$ ls -l total 0 -rw-r--r-- 1 ondrej ondrej 0 Feb 9 01:26 bar -rw-r--r-- 1 ondrej ondrej 0 Jan 1 00:00 foo?bar ondrej@howl:/tmp/php_sess$ find /tmp/php_sess -mmin +24 /tmp/php_sess/foo?bar ondrej@howl:/tmp/php_sess$ find /tmp/php_sess -mmin +24 | xargs rm rm: cannot remove `/tmp/php_sess/foo': No such file or directory ondrej@howl:/tmp/php_sess$ ls -l total 0 -rw-r--r-- 1 ondrej ondrej 0 Jan 1 00:00 foo?bar ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=61020&edit=1