Hi Michal,
On 2013-06-13 02:54, Michal Čihař wrote:
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...
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.
