Bugzilla Bug 88831

phpmyadmin installs
/usr/share/webapps/phpmyadmin/<version>/sqlscripts/mysql/<version>_create.sql
with world readable permissions.

That file contains the login password for the pma user, which means any user
with shell access to the system can log in to phpmyadmin and modify the PMA_*
tables.

Reproducible: Always
Steps to Reproduce:



Expected Results:  
The sqlscripts should be readble only by root.

php please advise.

CC'ing web-apps as they are listed in metadata.xml

the file is indeed worldreadable and contains the initial password for pma@localhost

The file (and the password therein) is only relevant for the very first
phpmyadmin install - the new password never get

The file (and the password therein) is only relevant for the very first
phpmyadmin install - the new password never get´s set when upgrading, even if
you follow the (mistaken) post-install instructions. Actually, if you upgrade
config.inc.php then phpmyadmin fails b/c the generated password is does not
match the one stored in MySQL. 

The ebuild should only generate the password if this is install (not upgrade).
If the intention was to change the pma password every time phpmyadmin is
upgraded, then this does not work.

Bumped in CVS, the 'mysql create' script is now installed with mode 0600.

Stable on x86.

Archs, please test and mark phpmyadmin-2.6.2-r1 stable.

Stable on ppc.

sparc stable.

Stable on hppa.

stable on amd64

Stable on alpha.

Ready for GLSA vote

As I understand this it is a very minor issue and only relevant on the very
first install. So there is no point in upgrading -> I vote for NO GLSA.

Agreed

It's hardly minor - shell users on my server could modify the PMA database
however they chose.  A lot of Gentoo servers only update such software when
there are security fixes such as this.

Hadn't thought of that possiblity -> reopening.

I tend to vote YES for GLSA release now.

Would upgrading change the compromised password ?

Comment #17: No, it would not. Also, the only possibility to abuse this is the
very first phpmyadmin install, the password never get

Comment #17: No, it would not. Also, the only possibility to abuse this is the
very first phpmyadmin install, the password never get´s updated/used
thereafter.

So this is really only a half fix, unless the original version is unmerged.

Yup, that

Yup, that´s related to the fact that the update instructions are broken.
You´d have to purge PMA user account and related permissions from MySQL DB and
only then the password would be changed if you follow the current instructions
and import/install the PMA DB. 

Right, okies, I have a bumped ebuild - diff between -r1 and -r2 (new):

--- phpmyadmin-2.6.2-r1.ebuild  2005-04-27 10:22:41.000000000 +0100
+++ phpmyadmin-2.6.2-r2.ebuild  2005-04-27 22:34:16.000000000 +0100
@@ -17,6 +17,14 @@ DEPEND=">=dev-db/mysql-3.23.32 <dev-db/m
        !<=dev-db/phpmyadmin-2.5.6"
 S=${WORKDIR}/${MY_P}

+pkg_setup() {
+       if has_version www-apps/wordpress; then
+               if test -d "${ROOT}/usr/share/webapps/${PN}"; then
+                       chmod 0600 "${ROOT}/usr/share/webapps/${PN}"/*/sqlscripts/mysql/*.sql
+               fi
+       fi
+}
+
 src_unpack() {
        unpack ${A}
        cd ${S}

So this will take care of upgrades, too.  Any issues with this ? :)  If not, I'll commit the bump and finally go home after 16 hours. ;)

s:www-apps-wordpress:dev-db/phpmyadmin:  Sorry, lack of sleep affecting hacking
abilities. :(

Well, the _real_ problem is that this does not solve the _real_ problem. :-) 

I.e, once a mischievous user gets the initial pma password, that password will remain valid for any number of upgrades unless the BOFH will ignore the instructions and really change the pma password manually.

So, besides this fix, the SQL script needs to be changed so that it actually changes the password for pma user when upgrading, like:

SET PASSWORD FOR 'pma'@'localhost' = PASSWORD('@pmapass@');

I

Well, the _real_ problem is that this does not solve the _real_ problem. :-) 

I.e, once a mischievous user gets the initial pma password, that password will remain valid for any number of upgrades unless the BOFH will ignore the instructions and really change the pma password manually.

So, besides this fix, the SQL script needs to be changed so that it actually changes the password for pma user when upgrading, like:

SET PASSWORD FOR 'pma'@'localhost' = PASSWORD('@pmapass@');

I´m no MySQL hacker but the password never got changed after upgrading and importing the SQL script...

Personal opinions are that as a distribution it isnt our position to randomly
change passwords for applications on upgrade.
The real issue here is that the install was setting insecure permissions, which
has since been rectified.
The repercussions of this are a potentially insecure password.
It should however be in our responsibility to recommend a password change to
our users.

I agree we need a GLSA, don't forget to state that people should consider their
password as potentially locally compromised and act accordingly (change
password, check integrity...)

#24, 25: Sounds reasonable, the ebuild should not be more complicated than
necessary... Just a recommendation to change the password should be enough. 

Thx everyone.

GLSA 200504-30

Hello,

config.inc.php is still world readable ...

should be :

chown apache:apache && chmod o-r config.inc.php

Regards

web-apps back to you.

chown apache:apache <-- this also seems wrong. No reason for the webserver to
need 
to have the ability to write to said file. root:apache 640 is ideal if apache 
needs to read from it.
btw pretty much any file apache owned is world readable as it's a trivial task
to 
just lynx http://localhost/filename

Created an attachment (id=57779) [edit]
fn_get_random_string() pseudo-random string generation

Brief description:
"This patch adds support for generation of pseudo-random string (33 bytes)
using a simplistic seeding "algorithm" that uses the /dev/urandom pseudo-random

numbers generator device to gather  entropy, and MD5 to calculate pseudo-random

sums to be used for calculating the final MD5 sum, that is, the pseudo-random
string to be used finally (ie. for generating a random password value to be
used
in automatically-created configuration or installation files)."

I hadn't time to work more on it, but it looks sane. The only thing that can be
a little issue is the entropy pool exhausting in server environments, that is,
our main targeted as of webapp-config. It would happen once we ask for more
entropy than the amount the kernel is prepared to fill, a common case when we
can't feed the pool with interrupt-generated entropy. A solution to this is to
use Robert Love's netdev-random patches that cause network drivers interrupts
to feed entropy to the pool, but I doubt on the impact of this patch (though
it's quite useful at first view).

Note the stupid simplicity of the patch itself, but I just thought it could
help.

Cheers,
Lorenzo.

2.6.2-r2 is in cvs.  config.inc.php is now installed 0640 root:apache.

Thx Aaron. This seems to only fix new installs so we'd still have to do a
manual chmod for existing install.s

Regarding the permissions on config.inc.php, when there is an existing install,
the config protected file retains the permissions root:root and 644.

# ls -l ._cfg0001_config.inc.php 
-rw-r--r--  1 root root 39199 May  3 01:48 ._cfg0001_config.inc.php 

I believe I've narrowed down the issue to when the file is config protected to
/usr/sbin/webapp-config, around line 1966 in whatever-vesion-I-have:

case "$my_type" in  
...
                config-owned)
                        # config-owned files are copied in, and then are
                        # owned by $G_CONFIG_UID:$G_CONFIG_GID

                        libsh_erun cp "$MY_APPDIR/$1/$2" "$3/$my_file"
                        libsh_erun chown "$G_CONFIG_UID:$G_CONFIG_GID"
"$3/$my_file"
                        libsh_erun chmod "$G_PERMS_CONFIGOWNED_FILE"
"$3/$my_file"
                        fn_add_contents "$MY_INSTALLCONTENTS" "file" "$my_type"
"$3" "$2" "$4"
                        ;;
...


So, basically, the owner and permissions are quite forced, and I don't see any
way to overcome this from the ebuild. Personally, I think webapp-config should
follow what portage does (the actual copy is done with movefile(), which
states:

"moves a file from src to dest, preserving all permissions and attributes;
mtime will be preserved even when moving across filesystems.  Returns true on
success and false on failure.  Move is atomic."

I find preserving all permissions and attributes to be quite important.

Elfyn please advise.

Apologies for the late response.  I'm cutting patches for this now that fixes
the permissions used for config files such as pma's config.inc.php, and also
fixes another fubar where site directories (typically /var/www/$site and
/var/www/$site/htdocs) are created mode 777.  There are a few remaining issues
I have to work out, but I'll have those sorted in a couple of hours (sorry,
keeps getting longer :/).

Elfyn, a couple of hours have passed, what is the current status?

Finally, we have an updated webapp-config (net-www/webapp-config-1.10-r13) to
deal with the problem above.  Permissions on configuration files are now
preserved, and webapp config files will be installed in the webroot 640
root:apache by default (requires that the webapp-config config file
(/etc/vhosts/webapp-config be etc-update'd).

This rev bump is package.mask'd as it _might_ break an app or two (initial
tests are good, though), and will stay there until I've checked out other
www-apps packages.  (/me promises this _will_ not take days ;)  Again,
apologies for the huge delays.

Please locally unmask and test with www-apps/phpmyadmin-2.6.2-r2.  Thanks !

Elfyn, we can mark webapp-config stable on this bug as well. Is it ready for
that?

It looks that way :)  I have 4 more packages to test out, and if they look good
this webapp-config will be going stable ASAP (it will also contain a fix for
bug #91785 once i've finished testing the above).

Thx Elfyn, please let me know when you have finished your tests.

Okies, webapp-config-1.10-r14 in the tree and fixes this issue (as well as the
issues from bug #87708 and bug #91785).  Tested with as many webapps in the
tree as possible, without issue.  Once all arches have marked it stable (being
called in bug #91785), this bug can finally die - or at least, one can hope. ;)

Remaining file permissions issue will be handled by the webapp-config update on
bug #91785 -> Closing this one.