Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 88831

Summary: dev-db/phpmyadmin installs template SQL insecurely.
Product: Gentoo Security Reporter: MAL <mal>
Component: VulnerabilitiesAssignee: Gentoo Security <security>
Status: RESOLVED FIXED    
Severity: minor CC: php-bugs, web-apps
Priority: High    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard: B4 [glsa] jaervosz
Package list:
Runtime testing required: ---
Attachments:
Description Flags
fn_get_random_string() pseudo-random string generation none

Description MAL 2005-04-12 04:30:01 UTC
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.
Comment 1 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-04-15 10:35:06 UTC
php please advise.
Comment 2 Matthias Geerdsen (RETIRED) gentoo-dev 2005-04-22 13:02:28 UTC
CC'ing web-apps as they are listed in metadata.xml

the file is indeed worldreadable and contains the initial password for pma@localhost
Comment 3 Jakub Moc (RETIRED) gentoo-dev 2005-04-23 04:07:56 UTC
The file (and the password therein) is only relevant for the very first phpmyadmin install - the new password never get
Comment 4 Jakub Moc (RETIRED) gentoo-dev 2005-04-23 04:07:56 UTC
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.
Comment 5 Elfyn McBratney (beu) (RETIRED) gentoo-dev 2005-04-25 04:02:14 UTC
Bumped in CVS, the 'mysql create' script is now installed with mode 0600.
Comment 6 Elfyn McBratney (beu) (RETIRED) gentoo-dev 2005-04-25 04:22:27 UTC
Stable on x86.

Archs, please test and mark phpmyadmin-2.6.2-r1 stable.
Comment 7 Michael Hanselmann (hansmi) (RETIRED) gentoo-dev 2005-04-25 10:45:16 UTC
Stable on ppc.
Comment 8 Gustavo Zacarias (RETIRED) gentoo-dev 2005-04-25 10:58:50 UTC
sparc stable.
Comment 9 Michael Hanselmann (hansmi) (RETIRED) gentoo-dev 2005-04-25 11:10:57 UTC
Stable on hppa.
Comment 10 Jan Brinkmann (RETIRED) gentoo-dev 2005-04-25 12:36:33 UTC
stable on amd64
Comment 11 Bryan Østergaard (RETIRED) gentoo-dev 2005-04-27 00:10:25 UTC
Stable on alpha.
Comment 12 Thierry Carrez (RETIRED) gentoo-dev 2005-04-27 00:35:57 UTC
Ready for GLSA vote
Comment 13 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-04-27 07:33:45 UTC
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.
Comment 14 Thierry Carrez (RETIRED) gentoo-dev 2005-04-27 08:58:24 UTC
Agreed
Comment 15 MAL 2005-04-27 09:16:18 UTC
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.
Comment 16 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-04-27 09:47:43 UTC
Hadn't thought of that possiblity -> reopening.
Comment 17 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-04-27 12:27:10 UTC
I tend to vote YES for GLSA release now.
Comment 18 Thierry Carrez (RETIRED) gentoo-dev 2005-04-27 13:36:37 UTC
Would upgrading change the compromised password ?
Comment 19 Jakub Moc (RETIRED) gentoo-dev 2005-04-27 14:01:37 UTC
Comment #17: No, it would not. Also, the only possibility to abuse this is the very first phpmyadmin install, the password never get
Comment 20 Jakub Moc (RETIRED) gentoo-dev 2005-04-27 14:01:37 UTC
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.
Comment 21 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-04-27 14:05:02 UTC
So this is really only a half fix, unless the original version is unmerged.
Comment 22 Jakub Moc (RETIRED) gentoo-dev 2005-04-27 14:48:28 UTC
Yup, that
Comment 23 Jakub Moc (RETIRED) gentoo-dev 2005-04-27 14:48:28 UTC
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. 
Comment 24 Elfyn McBratney (beu) (RETIRED) gentoo-dev 2005-04-27 14:55:19 UTC
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. ;)
Comment 25 Elfyn McBratney (beu) (RETIRED) gentoo-dev 2005-04-27 15:01:25 UTC
s:www-apps-wordpress:dev-db/phpmyadmin:  Sorry, lack of sleep affecting hacking abilities. :(
Comment 26 Jakub Moc (RETIRED) gentoo-dev 2005-04-27 15:47:56 UTC
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
Comment 27 Jakub Moc (RETIRED) gentoo-dev 2005-04-27 15:47:56 UTC
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...
Comment 28 John Mylchreest (RETIRED) gentoo-dev 2005-04-28 04:53:54 UTC
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.
Comment 29 Thierry Carrez (RETIRED) gentoo-dev 2005-04-28 09:38:54 UTC
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...)
Comment 30 Jakub Moc (RETIRED) gentoo-dev 2005-04-28 10:42:46 UTC
#24, 25: Sounds reasonable, the ebuild should not be more complicated than necessary... Just a recommendation to change the password should be enough. 
Comment 31 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-04-30 13:57:42 UTC
Thx everyone.

GLSA 200504-30
Comment 32 eromang 2005-05-01 02:51:59 UTC
Hello,

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

should be :

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

Regards
Comment 33 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-05-01 03:03:35 UTC
web-apps back to you.
Comment 34 solar (RETIRED) gentoo-dev 2005-05-01 06:29:51 UTC
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
Comment 35 Lorenzo Hernández García-Hierro 2005-05-01 16:13:15 UTC
Created attachment 57779 [details, diff]
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.
Comment 36 Aaron Walker (RETIRED) gentoo-dev 2005-05-02 17:56:45 UTC
2.6.2-r2 is in cvs.  config.inc.php is now installed 0640 root:apache.
Comment 37 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-05-02 22:16:57 UTC
Thx Aaron. This seems to only fix new installs so we'd still have to do a manual chmod for existing install.s
Comment 38 Robert Paskowitz (RETIRED) gentoo-dev 2005-05-02 23:35:59 UTC
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 
Comment 39 Robert Paskowitz (RETIRED) gentoo-dev 2005-05-03 00:29:17 UTC
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.
Comment 40 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-05-03 09:50:50 UTC
Elfyn please advise.
Comment 41 Elfyn McBratney (beu) (RETIRED) gentoo-dev 2005-05-03 16:38:53 UTC
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 :/).
Comment 42 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-05-05 22:22:47 UTC
Elfyn, a couple of hours have passed, what is the current status?
Comment 43 Elfyn McBratney (beu) (RETIRED) gentoo-dev 2005-05-07 07:52:38 UTC
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 !
Comment 44 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-05-07 10:36:56 UTC
Elfyn, we can mark webapp-config stable on this bug as well. Is it ready for that?
Comment 45 Elfyn McBratney (beu) (RETIRED) gentoo-dev 2005-05-07 11:22:59 UTC
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).
Comment 46 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-05-07 11:31:15 UTC
Thx Elfyn, please let me know when you have finished your tests.
Comment 47 Elfyn McBratney (beu) (RETIRED) gentoo-dev 2005-05-08 22:19:20 UTC
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. ;)
Comment 48 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-05-15 08:56:32 UTC
Remaining file permissions issue will be handled by the webapp-config update on bug #91785 -> Closing this one.