Bug#712011: [phpmyadmin] Configuration is lost despite saving
Hi Dne Wed, 12 Jun 2013 20:41:41 -0400 Filipus Klutiero chea...@gmail.com napsal(a): Hehe, me too ;-) I thought about this when reporting, but ended up writing nothing because: * I'm not sure why we use the current authorization process * I'm not much knowledgeable in the area anyway The reason why I imagine config.inc.php is generally not writable by www-data is to prevent a compromise of phpMyAdmin caused by an exploit of another web application. I don't think making it writable would be /insecure/, since the web server isn't supposed to run any code, but I agree the current situation is much more secure. If that's the rationale, I guess the solution would be to isolate phpMyAdmin from other applications (for example, by having phpMyAdmin run as a phpmyadmin user rather than www-data). I see that suPHP allows something like that, but I don't know a mature solution doing that :-( No the problem is how to protect the setup page as you don't want to have publicly accessible page which can alter your configuration. Using hardcoded credentials in the script is of course bad idea and there is no other working authentication at that point. That's why require some action done on the system both upstream and in Debian (though it's slightly different). In Debian we've used debconf to ask for password and configured webserver to protect the setup script, but it proven to be bad idea as user is free to choose any server and in case he would choose something we do not support the setup would be unsecured. Also most people don't see low priority debconf questions... -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Bug#712011: [phpmyadmin] Configuration is lost despite saving
Hi Michal, On 2013-06-13 02:54, Michal Čihař wrote: Hi Dne Wed, 12 Jun 2013 20:41:41 -0400 Filipus Klutierochea...@gmail.com napsal(a): Hehe, me too ;-) I thought about this when reporting, but ended up writing nothing because: * I'm not sure why we use the current authorization process * I'm not much knowledgeable in the area anyway The reason why I imagine config.inc.php is generally not writable by www-data is to prevent a compromise of phpMyAdmin caused by an exploit of another web application. I don't think making it writable would be /insecure/, since the web server isn't supposed to run any code, but I agree the current situation is much more secure. If that's the rationale, I guess the solution would be to isolate phpMyAdmin from other applications (for example, by having phpMyAdmin run as a phpmyadmin user rather than www-data). I see that suPHP allows something like that, but I don't know a mature solution doing that :-( No the problem is how to protect the setup page as you don't want to have publicly accessible page which can alter your configuration. Using hardcoded credentials in the script is of course bad idea and there is no other working authentication at that point. That's why require some action done on the system both upstream and in Debian (though it's slightly different). In Debian we've used debconf to ask for password and configured webserver to protect the setup script, but it proven to be bad idea as user is free to choose any server and in case he would choose something we do not support the setup would be unsecured. Also most people don't see low priority debconf questions... Access control for the setup page is definitely a problem. Not having to create a user would certainly enhance phpMyAdmin's usability. But I do not see how the setup page's access control would cause the problem discussed here with the double saving process. HTTP authentication is entirely secure, there is no need to minimize the attack window. The way I see it, if an administrator wants to change 2 settings, he would normally have to proceed this way: 1. pma-configure 2. Change setting 1. 3. Change setting 2. 4. pma-secure The current design allows the following method: 1. Change setting 1. 2. Change setting 2. 3. pma-configure 4. Save settings 5. pma-secure This design may be confusing and less convenient, but it has the merit of reducing the attack window's size (from 2 steps to a single one in this example). However, the attack in question here is one on config.inc.php (via liberal permissions), not on the setup page.
Bug#712011: [phpmyadmin] Configuration is lost despite saving
Hi Dne Tue, 11 Jun 2013 22:22:40 -0400 Filipus Klutiero chea...@gmail.com napsal(a): phpMyAdmin's install script (setup/index.php) provides a GUI to configure phpMyAdmin. For example, one can change the limit on the number of characters from a field shown. To do that, one would go to the Main panel page, to the Browse mode tab, change the number in the form then click Save. However, saving that way doesn't actually save the settings. If one leaves the script after saving, configuration will not be applied (and eventually, will be lost). To actually save changes, one needs to click Save one more time on the page reached after saving the first time (in the Configuration file area). Then, a message will confirm that the changes were saved. The first save merely writes the changes to the PHP session. The second save writes them to config.inc.php, as one would expect. The way the install script works is definitely not Debian-specific. Unless some warning or tooltip is supposed to appear, this is an upstream issue. I'm not sure what led to such a design, but the complicated authorization process for modifying configuration may be the main reason. One needs to unsecure the configuration file before performing modifications. Presumably, with the current design, less time has to be spent in an insecure state. A quick fix would be to keep the current design avoiding to mislead users. I suppose labeling the first save button as OK and adding some warning (say a Changes are only stored to your session. Don't forget to save them permanently when done popup) could achieve that. I've made this change upstream. A good fix would implement proper access control for configuration and get rid of the second step. I'm open to suggestions how to do this. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Bug#712011: [phpmyadmin] Configuration is lost despite saving
Hi Michal, On 2013-06-12 03:00, Michal Čihař wrote: Hi Dne Tue, 11 Jun 2013 22:22:40 -0400 Filipus Klutierochea...@gmail.com napsal(a): phpMyAdmin's install script (setup/index.php) provides a GUI to configure phpMyAdmin. For example, one can change the limit on the number of characters from a field shown. To do that, one would go to the Main panel page, to the Browse mode tab, change the number in the form then click Save. However, saving that way doesn't actually save the settings. If one leaves the script after saving, configuration will not be applied (and eventually, will be lost). To actually save changes, one needs to click Save one more time on the page reached after saving the first time (in the Configuration file area). Then, a message will confirm that the changes were saved. The first save merely writes the changes to the PHP session. The second save writes them to config.inc.php, as one would expect. The way the install script works is definitely not Debian-specific. Unless some warning or tooltip is supposed to appear, this is an upstream issue. I'm not sure what led to such a design, but the complicated authorization process for modifying configuration may be the main reason. One needs to unsecure the configuration file before performing modifications. Presumably, with the current design, less time has to be spent in an insecure state. A quick fix would be to keep the current design avoiding to mislead users. I suppose labeling the first save button as OK and adding some warning (say a Changes are only stored to your session. Don't forget to save them permanently when done popup) could achieve that. I've made this change upstream. Thank you! A good fix would implement proper access control for configuration and get rid of the second step. I'm open to suggestions how to do this. Hehe, me too ;-) I thought about this when reporting, but ended up writing nothing because: * I'm not sure why we use the current authorization process * I'm not much knowledgeable in the area anyway The reason why I imagine config.inc.php is generally not writable by www-data is to prevent a compromise of phpMyAdmin caused by an exploit of another web application. I don't think making it writable would be /insecure/, since the web server isn't supposed to run any code, but I agree the current situation is much more secure. If that's the rationale, I guess the solution would be to isolate phpMyAdmin from other applications (for example, by having phpMyAdmin run as a phpmyadmin user rather than www-data). I see that suPHP allows something like that, but I don't know a mature solution doing that :-( -- Filipus Klutiero http://www.philippecloutier.com
Bug#712011: [phpmyadmin] Configuration is lost despite saving
Package: phpmyadmin Version: 4:4.0.3-1 Severity: normal phpMyAdmin's install script (setup/index.php) provides a GUI to configure phpMyAdmin. For example, one can change the limit on the number of characters from a field shown. To do that, one would go to the Main panel page, to the Browse mode tab, change the number in the form then click Save. However, saving that way doesn't actually save the settings. If one leaves the script after saving, configuration will not be applied (and eventually, will be lost). To actually save changes, one needs to click Save one more time on the page reached after saving the first time (in the Configuration file area). Then, a message will confirm that the changes were saved. The first save merely writes the changes to the PHP session. The second save writes them to config.inc.php, as one would expect. The way the install script works is definitely not Debian-specific. Unless some warning or tooltip is supposed to appear, this is an upstream issue. I'm not sure what led to such a design, but the complicated authorization process for modifying configuration may be the main reason. One needs to unsecure the configuration file before performing modifications. Presumably, with the current design, less time has to be spent in an insecure state. A quick fix would be to keep the current design avoiding to mislead users. I suppose labeling the first save button as OK and adding some warning (say a Changes are only stored to your session. Don't forget to save them permanently when done popup) could achieve that. A good fix would implement proper access control for configuration and get rid of the second step. --- System information. --- Architecture: i386 Kernel: Linux 3.2.0-4-amd64 Debian Release: 7.0 990 stable security.debian.org 990 stable debian.mirror.iweb.ca 500 unstable debian.mirror.iweb.ca 1 experimental debian.mirror.iweb.ca --- Package information. --- Depends (Version) | Installed -+-=== libapache2-mod-php5 | 5.4.4-14 OR libapache2-mod-php5filter | OR php5-cgi | 5.4.0-3 OR php5-fpm | OR php5 | 5.4.4-14 php5-mysql | 5.4.4-14 OR php5-mysqli | OR php5-mysqlnd | php5-mcrypt | 5.4.4-14 php5-json | perl | 5.14.2-21 debconf (= 0.5) | 1.5.49 OR debconf-2.0 | dbconfig-common | 1.8.47+nmu1 ttf-dejavu-core | 2.33-3 php-gettext | 1.0.11-1 libjs-jquery | 1.7.2+dfsg-1 libjs-jquery-ui | 1.8.ooops.21+dfsg-2 libjs-jquery-cookie | 6-1 libjs-jquery-mousewheel | 6-1 libjs-jquery-event-drag | 6-1 libjs-jquery-tablesorter | 6-1 libjs-codemirror | 2.23-1 libjs-underscore | 1.1.6-1+deb7u1 ucf (= 0.28) | 3.0025+nmu3 Recommends (Version) | Installed ===-+-=== apache2 | 2.2.22-13 OR lighttpd | 1.4.30-1 OR httpd | php5-gd | 5.4.4-14 mysql-client | Suggests (Version) | Installed ===-+-=== mysql-server | 5.5.31+dfsg-0+wheezy1 www-browser | -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
