| Summary: | dev-db/phpmyadmin installs template SQL insecurely. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Gentoo Security | Reporter: | MAL <mal> | ||||
| Component: | Vulnerabilities | Assignee: | 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
MAL
2005-04-12 04:30:01 UTC
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 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.
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. |
