[PHP-DEV] Bug #15375 Updated: safe_mode wrappers fail for MySQL (other exts?)
ID: 15375 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: MySQL related Operating System: All PHP Version: 4.1.1 Assigned To: zak New Comment: I generally agree on Rasmus' feedback on the issue, so i'll leave it closed. However, since this naturally works with remote mysql-servers, setting up a server where you have the create-permission isnt really much of a hazzle. Previous Comments: [2002-02-05 10:15:39] [EMAIL PROTECTED] It works even if you are connecting to remote mysql server over tcp/ip, so I don't think this is only mysql related issue. [2002-02-05 09:53:36] [EMAIL PROTECTED] Verified that the exploit allows any file readable by the MySQL server to be viewed via this technique. Note that forbidding the MySQL user CREATE permission does make the exploit less convenient for the attacker. The MySQL dev team is looking at ways to reduce this risk via MySQL permission behavior in the server. Given Rasmus' feedback on the issue, I am closing this as a PHP bug. Hopefully, the MySQL dev team should be able eliminate or reduce this risk. If we can't completely resolve it, I will re-examine this bug. --zak@[mysql|php].com [2002-02-05 09:53:11] [EMAIL PROTECTED] Verified that the exploit allows any file readable by the MySQL server to be viewed via this technique. Note that forbidding the MySQL user CREATE permission does make the exploit less convenient for the attacker. The MySQL dev team is looking at ways to reduce this risk via MySQL permission behavior in the server. Given Rasmus' feedback on the issue, I am closing this as a PHP bug. Hopefully, the MySQL dev team should be able eliminate or reduce this risk. If we can't completely resolve it, I will re-examine this bug. --zak@[mysql|php].com [2002-02-05 06:22:51] [EMAIL PROTECTED] Humility is a dish best served lukewarm... I should have read more carefully. :) While Rasmus has spoken on this issue, but I will take a closer look at it tomorrow. [2002-02-05 06:08:01] [EMAIL PROTECTED] while that would be a obvious solution, this is an CLIENT-matter (the client sends the file) - and the File-privilege is only affecting the ability to load files that are stored on the server (and not in the client). The problem discussed is in the way that PHP will allow for any user to upload an arbitary file form the local server (where php runs) to the MySQL-server. IE: I set up a server running MySQL (or faking it, whatever) .. which just implements the receiver-part of the send_file_to_server-function in libmysql. This will allow me to transfer any file that the user PHP runs under on the server has access to, regardless of safe_mode, etc. The keyword 'local' is probably the cause of confusion, since this causes the file to be loaded from the client - and not the server (where the File-privilege has effect). The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/15375 -- Edit this bug report at http://bugs.php.net/?id=15375edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug #15375: safe_mode wrappers fail for MySQL (other exts?)
From: [EMAIL PROTECTED] Operating system: All PHP version: 4.1.1 PHP Bug Type: MySQL related Bug description: safe_mode wrappers fail for MySQL (other exts?) A message was posted at bugtraq earlier about a problem with safe_mode and the mysql-library used. the message is available here: http://www.orakel.ntnu.no/~matslin/php4_safe_mode.txt I searched the bugdb, but the bug doesnt not seem to be reported. As the author says in the mail, this may be a problem with other extensions as well. As far as i can see, this could probably be fixed in the send_file_to_server-function in libmysql.c, more specific somewhere around line 1776 (there is also some mention about this in the mail). The 'bug' makes it possible to read all files readable for php, even if its running in safe mode, basedir-restrictions etc. More info in the mail. -- Edit bug report at http://bugs.php.net/?id=15375edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15375r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15375r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15375r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15375r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15375r=support Expected behavior: http://bugs.php.net/fix.php?id=15375r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15375r=notenoughinfo -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug #15288 Updated: Image*-functions being avail even if they're not implemented by gd
ID: 15288 Updated by: [EMAIL PROTECTED] Old Summary: Image*-functions being avail even if they're not implemented by gd Reported By: [EMAIL PROTECTED] Status: Open Old Bug Type: Feature/Change Request Bug Type: GD related Operating System: All PHP Version: 4.1.1 New Comment: I've also created a patch that remove the functions from the binary/module (if they're not available); http://software.e-mats.org/patches/gd.c-diff-2002-02-02 (i also moved this to 'GD related'.) Previous Comments: [2002-01-30 10:41:52] [EMAIL PROTECTED] I've made a small patch based on the CVS-version that remove functions that are not available. I'm not sure if i caught them all, but i made a try :-) I've not removed the original error-messages (gd was compiled without support..), so they're still in there (maybe a define or ./configure-option to select what way error-reporting should be done). the diff: http://software.e-mats.org/patches/gd.c-diff-2002-01-30 the source: http://software.e-mats.org/patches/gd.c-cvs-2002-01-30 [2002-01-30 08:51:11] [EMAIL PROTECTED] I'm +1 on your patch as well, can you make it against the latest CVS version? I'll make sure it gets committed then. regards, Derick [2002-01-30 08:47:03] [EMAIL PROTECTED] This is excactly the point i'm trying to make. To me it seems like the most logical thing would be to not implement the function at all, since this would make function_exists() work as expected. Implementing the function (to give an error message) - even though its not available seems kinda useless, since this also makes it harder to make a general solution. [2002-01-30 08:13:23] [EMAIL PROTECTED] This one seems really a mess to me (declaring function which output not implemented) when we have 'function_exists()'. Reopening for discussion. [2002-01-30 07:39:49] [EMAIL PROTECTED] .. this does however not cover the TTF*-functions. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/?id=15288 Edit this bug report at http://bugs.php.net/?id=15288edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #15330 Updated: An efficient way to access the last element of an array is sorely missed
ID: 15330 Comment by: [EMAIL PROTECTED] Old Reported By: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: N/A PHP Version: 4.1.1 New Comment: While there is no way to set the internal pointer (afaik) to a given element #, you can set the pointer to the first/last/next/previous item. http://se.php.net/manual/en/function.end.php end -- Set the internal pointer of an array to its last element. -- mats Previous Comments: [2002-02-01 14:07:08] [EMAIL PROTECTED] There seems to be no easy and efficient way to access the last element of an array (assuming you don't already know the key to that element). The most concise, though not terribly efficient workaround I have discovered is... $array[array_pop(array_keys($array))] ...which first extracts all the keys of the array, then pops off the last key and uses it as an index into the array. Fairly easy to write and understand (though bulky), but horribly inefficient. Perhaps there is a place for new array_lastkey($array), array_firstkey($array), and array_element_key($array, $n) functions. The first of these functions would simply return the last key in the array (or null if the array is empty). The second would return the first key in the array (or null). In the third, $n would be a numeric index into the array, totally unrelated to the array's keys. A positive number would indicate how far into the array to go, a negative number would indicate how far backward into the array to go, while 0 or an out of bounds index might either quietly return a null or might throw an error or warning. Some Examples: $array = array( 1 = One, two = Two, -3 = Minus Three ); echo $array[array_firstkey($array)]; // returns One because array_firstkey() returns 1 echo $array[array_lastkey($array)]; // returns Minus Three because array_lastkey() returns -3 echo $array[array_element_key($array,1)]; // returns One because array_element_key() returns 1 echo $array[array_element_key($array,2)]; // returns Two because array_element_key() returns two echo $array[array_element_key($array,-2)]; // returns Two because array_element_key() returns two echo $array[array_element_key($array,-1)]; // returns Minus Three because array_element_key() returns -3 Edit this bug report at http://bugs.php.net/?id=15330edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #15288 Updated: Image*-functions being avail even if they're not implemented by gd
ID: 15288 User updated by: [EMAIL PROTECTED] Old Summary: Image*-functions being avail even if they're not implemented by gd Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Feature/Change Request Operating System: All PHP Version: 4.1.1 New Comment: .. this does however not cover the TTF*-functions. Previous Comments: [2002-01-29 23:06:03] [EMAIL PROTECTED] There is already a clean way to check which image formats are supported: http://www.php.net/manual/en/function.imagetypes.php [2002-01-29 20:53:30] [EMAIL PROTECTED] The Image*-functions specific for different formats are available even if they're not supported in GD. Even though this is understandable, a better practice would probably be to disable these functions, since they're not available.(so they can be checked for existance in runtime, instead of relying on errors passed back from gd) It shouldnt be much of a change, since i was able to create the desired effect using a few #ifdef's - and i've only got spare knowledge of c. http://software.e-mats.org/patches/gd_4.1.1.diff contains the diff for the gd.c-file from 4.1.1. that i used for testing. Edit this bug report at http://bugs.php.net/?id=15288edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #15288 Updated: Image*-functions being avail even if they're not implemented by gd
ID: 15288 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: All PHP Version: 4.1.1 New Comment: This is excactly the point i'm trying to make. To me it seems like the most logical thing would be to not implement the function at all, since this would make function_exists() work as expected. Implementing the function (to give an error message) - even though its not available seems kinda useless, since this also makes it harder to make a general solution. Previous Comments: [2002-01-30 08:13:23] [EMAIL PROTECTED] This one seems really a mess to me (declaring function which output not implemented) when we have 'function_exists()'. Reopening for discussion. [2002-01-30 07:39:49] [EMAIL PROTECTED] .. this does however not cover the TTF*-functions. [2002-01-29 23:06:03] [EMAIL PROTECTED] There is already a clean way to check which image formats are supported: http://www.php.net/manual/en/function.imagetypes.php [2002-01-29 20:53:30] [EMAIL PROTECTED] The Image*-functions specific for different formats are available even if they're not supported in GD. Even though this is understandable, a better practice would probably be to disable these functions, since they're not available.(so they can be checked for existance in runtime, instead of relying on errors passed back from gd) It shouldnt be much of a change, since i was able to create the desired effect using a few #ifdef's - and i've only got spare knowledge of c. http://software.e-mats.org/patches/gd_4.1.1.diff contains the diff for the gd.c-file from 4.1.1. that i used for testing. Edit this bug report at http://bugs.php.net/?id=15288edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #15288 Updated: Image*-functions being avail even if they're not implemented by gd
ID: 15288 User updated by: [EMAIL PROTECTED] Old Summary: Image*-functions being avail even if they're not implemented by gd Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Open Bug Type: Feature/Change Request Operating System: All PHP Version: 4.1.1 New Comment: I've made a small patch based on the CVS-version that remove functions that are not available. I'm not sure if i caught them all, but i made a try :-) I've not removed the original error-messages (gd was compiled without support..), so they're still in there (maybe a define or ./configure-option to select what way error-reporting should be done). the diff: http://software.e-mats.org/patches/gd.c-diff-2002-01-30 the source: http://software.e-mats.org/patches/gd.c-cvs-2002-01-30 Previous Comments: [2002-01-30 08:51:11] [EMAIL PROTECTED] I'm +1 on your patch as well, can you make it against the latest CVS version? I'll make sure it gets committed then. regards, Derick [2002-01-30 08:47:03] [EMAIL PROTECTED] This is excactly the point i'm trying to make. To me it seems like the most logical thing would be to not implement the function at all, since this would make function_exists() work as expected. Implementing the function (to give an error message) - even though its not available seems kinda useless, since this also makes it harder to make a general solution. [2002-01-30 08:13:23] [EMAIL PROTECTED] This one seems really a mess to me (declaring function which output not implemented) when we have 'function_exists()'. Reopening for discussion. [2002-01-30 07:39:49] [EMAIL PROTECTED] .. this does however not cover the TTF*-functions. [2002-01-29 23:06:03] [EMAIL PROTECTED] There is already a clean way to check which image formats are supported: http://www.php.net/manual/en/function.imagetypes.php The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/?id=15288 Edit this bug report at http://bugs.php.net/?id=15288edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #15288: Image*-functions being avail even if they're not implemented by gd
From: [EMAIL PROTECTED] Operating system: All PHP version: 4.1.1 PHP Bug Type: Feature/Change Request Bug description: Image*-functions being avail even if they're not implemented by gd The Image*-functions specific for different formats are available even if they're not supported in GD. Even though this is understandable, a better practice would probably be to disable these functions, since they're not available.(so they can be checked for existance in runtime, instead of relying on errors passed back from gd) It shouldnt be much of a change, since i was able to create the desired effect using a few #ifdef's - and i've only got spare knowledge of c. http://software.e-mats.org/patches/gd_4.1.1.diff contains the diff for the gd.c-file from 4.1.1. that i used for testing. -- Edit bug report at: http://bugs.php.net/?id=15288edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
