Re: [PHP] session.save_path is a big security hole!
Unfortunetly setting quotes (eg for apache user)doesnt prevent from flooding out entire disk. For example i can have running a script that will check user directories every 15 minutes and if some directory will contain large amount of apache generated files, user account will be disabled and files will be removed. But what to do if for example i have 500 users and every user directory is flooded out with bogus files? Actually i can imaging some sort of terrorising the server this that kind of attack :) AFAIK it's possible to set a limit on the number of inodes as well as space. So that prevents a gazillion 1byte files from killing the server. -- http://www.raditha.com/php/progress.php A progress bar for PHP file uploads. -- http://www.raditha.com/php/progress.php A progress bar for PHP file uploads. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] session.save_path is a big security hole!
Theres absolutely no control over session.save_path parameter in php. By setting it to every directory he wants, every user can: 1. (!!!) Absolutely easily generate new sessions with any content for every site on server. 2. Delete other users sessions by setting gc to 100 and probably legal files starting with sess_*. 3. Flood every http server writable directory with thousands or millions files. session.save_path should be controlled under open_basedir variable or some other mechanism. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] session.save_path is a big security hole!
* Thus wrote Rx ([EMAIL PROTECTED]): Theres absolutely no control over session.save_path parameter in php. By setting it to every directory he wants, every user can: You can set the value with php_admin_value save_path /tmp 1. (!!!) Absolutely easily generate new sessions with any content for every site on server. prevented with open_basedir. Can you demonstrate how you expect to do this? Using open_basedir most can also resovle this issue. 2. Delete other users sessions by setting gc to 100 and probably legal files starting with sess_*. This might be a valid point if you also mention that if the user sets gc_maxlifetime to a value of 1 or lower than cache_expire, and the gc_probablity at 100. Although I havn't tested, and probably should be. I'm also not sure but technically gc_maxlifetime should never be lower than cache_expire, if this is the case then there no issues with setting gc_probablity to 100, cept for a bunch of overhead for the users script. 3. Flood every http server writable directory with thousands or millions files. Don't allow the person to create files. That is the only way to prevent a user of doing this regardless of the save_path parameter. session.save_path should be controlled under open_basedir variable or some other mechanism. Perhaps a better solution would be to have a php.ini setting for disabling ini settings: disable_ini session.save_path,session.gc_maxlifetime Curt -- I used to think I was indecisive, but now I'm not so sure. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] session.save_path is a big security hole!
Curt Zirzow [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] * Thus wrote Rx ([EMAIL PROTECTED]): Theres absolutely no control over session.save_path parameter in php. By setting it to every directory he wants, every user can: You can set the value with php_admin_value save_path /tmp If i set php_admin_value, user STILL can change the value with ini_set()! I tested it. php_admin_value only prevents changing value from .htaccess file. Actually this also make sense for me, values set by php_admin_value shouldnt be allowed to change ever. 1. (!!!) Absolutely easily generate new sessions with any content for every site on server. prevented with open_basedir. Can you demonstrate how you expect to do this? Using open_basedir most can also resovle this issue. You didnt understand. I change save.session_path to other's site session directory, do session_start(), write every variable what i want, write down session number, go to this site and using this generated session. You cannt prevent this ever! 2. Delete other users sessions by setting gc to 100 and probably legal files starting with sess_*. This might be a valid point if you also mention that if the user sets gc_maxlifetime to a value of 1 or lower than cache_expire, and the gc_probablity at 100. Although I havn't tested, and probably should be. I'm also not sure but technically gc_maxlifetime should never be lower than cache_expire, if this is the case then there no issues with setting gc_probablity to 100, cept for a bunch of overhead for the users script. Hm, what the connection with cache_expire? User set gc to 100 and maxlifetime to 1 sec, then that script will delete every session in directory. 3. Flood every http server writable directory with thousands or millions files. Don't allow the person to create files. That is the only way to prevent a user of doing this regardless of the save_path parameter. No, its not a valid point. Every user can access only certain directory with apache permissions or with his own. And i know which directory belongs to whom. However with session.save_path user can flood EVERY directory on server, and even i wont know which user did that! session.save_path should be controlled under open_basedir variable or some other mechanism. Perhaps a better solution would be to have a php.ini setting for disabling ini settings: disable_ini session.save_path,session.gc_maxlifetime Well i agree, that should be done too. Curt -- I used to think I was indecisive, but now I'm not so sure. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] session.save_path is a big security hole!
* Thus wrote Rx ([EMAIL PROTECTED]):
Curt Zirzow [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
* Thus wrote Rx ([EMAIL PROTECTED]):
You can set the value with
php_admin_value save_path /tmp
If i set php_admin_value, user STILL can change the value with ini_set()! I
tested it. php_admin_value only prevents changing value from .htaccess file.
Actually this also make sense for me, values set by php_admin_value shouldnt
be allowed to change ever.
I was not aware of this.
You didnt understand. I change save.session_path to other's site session
directory, do session_start(), write every variable what i want, write down
session number, go to this site and using this generated session. You cannt
prevent this ever!
hm. yes, I see your point on this.
2. Delete other users sessions by setting gc to 100 and probably legal
files
starting with sess_*.
I'm also not sure but technically gc_maxlifetime should never be
lower than cache_expire, if this is the case then there no issues
with setting gc_probablity to 100, cept for a bunch of overhead for
the users script.
Hm, what the connection with cache_expire? User set gc to 100 and
maxlifetime to 1 sec, then that script will delete every session in
directory.
The conection is that the gc shouldn't clean up a session that has
a lifetime still. so if gc_maxlifetime = 9 and cache_expire = 10,
gc shouldn't clean up anything less than 11.
But then, this is a mute point since if you change cache_expire
at run time, gc wont know the difference.
Don't allow the person to create files. That is the only way to
prevent a user of doing this regardless of the save_path parameter.
No, its not a valid point. Every user can access only certain directory with
apache permissions or with his own. And i know which directory belongs to
whom. However with session.save_path user can flood EVERY directory on
server, and even i wont know which user did that!
Thanks for clarifying this. I was not thinking on the same line as
you. So a malicious user can do something like:
while (1) {
session_save_path(pick_a_writeabledir());
session_start();
session_write_close();
}
Curt
--
I used to think I was indecisive, but now I'm not so sure.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] session.save_path is a big security hole!
You didnt understand. I change save.session_path to other's site session directory, do session_start(), write every variable what i want, write down session number, go to this site and using this generated session. You cannt prevent this ever! Does enabling safe_mode counter any of these writing file issues? We all know the solution is to have a dedicated server, of course. :) -- ---John Holmes... Amazon Wishlist: www.amazon.com/o/registry/3BEXC84AB3A5E/ php|architect: The Magazine for PHP Professionals www.phparch.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] session.save_path is a big security hole!
* Thus wrote John W. Holmes ([EMAIL PROTECTED]): You didnt understand. I change save.session_path to other's site session directory, do session_start(), write every variable what i want, write down session number, go to this site and using this generated session. You cannt prevent this ever! Does enabling safe_mode counter any of these writing file issues? unfortantly no. We all know the solution is to have a dedicated server, of course. :) Or a jailed system, usually a bit cheaper for the client. Perhaps that is the best way to go as a hosting company, and only offer a really locked down (disabling a bunch of functions) to simple virtual hosts. Curt -- I used to think I was indecisive, but now I'm not so sure. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] session.save_path is a big security hole!
M, very interesting thread, thanx for starting this. Good comments curt. 1. (!!!) Absolutely easily generate new sessions with any content for every site on server. It's because of the 'suspect' nature of sessions and cookies that i never place userid,username or password in sessions. My tactic is to aways have 2 column mysql table and store session identifier and corresponding userid in it. So even if someone does create a bogus session they still have to find a way to insert a userid into the mysql db. 3. Flood every http server writable directory with thousands or millions files. set quotas. Some admins even set quota for the root user, which is inconvinient by safe. -- http://www.raditha.com/php/progress.php A progress bar for PHP file uploads. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] session.save_path is a big security hole!
Raditha Dissanayake [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] M, very interesting thread, thanx for starting this. Good comments curt. 1. (!!!) Absolutely easily generate new sessions with any content for every site on server. It's because of the 'suspect' nature of sessions and cookies that i never place userid,username or password in sessions. My tactic is to aways have 2 column mysql table and store session identifier and corresponding userid in it. So even if someone does create a bogus session they still have to find a way to insert a userid into the mysql db. Yep, there are many ways. But i think 90% of php users doesnt even realize that every user on the same server can actually get full access to their account through sessions. And i bet it can be done now on 90% of the hosting companies :D The only workaround i thought out on system level, without disabling ini_set is to create for every user unique session folder, with random 20-30 chars length, and to set this dir for every user through php_admin_value. But theres still next problem below 3. Flood every http server writable directory with thousands or millions files. set quotas. Some admins even set quota for the root user, which is inconvinient by safe. Unfortunetly setting quotes (eg for apache user)doesnt prevent from flooding out entire disk. For example i can have running a script that will check user directories every 15 minutes and if some directory will contain large amount of apache generated files, user account will be disabled and files will be removed. But what to do if for example i have 500 users and every user directory is flooded out with bogus files? Actually i can imaging some sort of terrorising the server this that kind of attack :) -- http://www.raditha.com/php/progress.php A progress bar for PHP file uploads. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
