Bugzilla Bug 46242

The mysql bugreporting utility uses a hardcoded filename to create a temporary
file if a bugreport is aborted. This can be exploited for a symbolic link
attack which can lead to destruction of data and DoS (e.g. overwriting
/etc/passwd).


Reproducible: Didn't try
Steps to Reproduce:
1.
2.
3.




See on bugtraq:
http://www.securityfocus.com/bid/9976/discussion/

The issue has been fixed in the mysql development source repository and will be
contained in the next release of MySQL.

The fix they used is:
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2004/03/24 20:27:07+01:00 serg@serg.mylan 
#   protection against "ln -s /etc/passwd /tmp/failed-mysql-bugreport"
# 
# scripts/mysqlbug.sh
#   2004/03/24 20:27:05+01:00 serg@serg.mylan +2 -2
#   protection against "ln -s /etc/passwd /tmp/failed-mysql-bugreport"
# 
diff -Nru a/scripts/mysqlbug.sh b/scripts/mysqlbug.sh
--- a/scripts/mysqlbug.sh       Tue Mar 30 07:12:52 2004
+++ b/scripts/mysqlbug.sh       Tue Mar 30 07:12:52 2004
@@ -252,9 +252,9 @@
 if cmp -s $TEMP $TEMP.x
 then
   echo "File not changed, no bug report submitted."
-  cp $TEMP /tmp/failed-mysql-bugreport
+  mv -f $TEMP /tmp/failed-mysql-bugreport
   echo "The raw bug report exists in /tmp/failed-mysql-bugreport"
-  echo "If you use this remember that the first lines of the report now is a
lie.."
+  echo "If you use this remember that the first lines of the report are now a
lie.."
   exit 1
 fi

I patched the script /usr/bin/mysqlbug on my system and will attach the patched
script to this bug.

Created an attachment (id=28371) [details]
Patched mysqlbug script

mysql folks -- can you review/comment?

security: impact rating = verylow
mysql4.0 is reasonably bugless at this point in time.

*** Bug 45727 has been marked as a duplicate of this bug. ***

Robin -- bug-free as it may be, we should still look at patching this.  We
certainly get a boat load of bogus "package foo doesn't compile" bug reports
and I'm sure mysql does as well.

Fixed in (to be released) 4.0.19.
Wait or patch ?

-r1 in cvs

Waiting for stable...
Arches : please test :)

-K

According to robbat2's latest changelog entry for this, there are some automake
changes that need to be tested first.  Can someone elaborate on this and what
criteria we can use to gauge if those changes are working ok?

the automake stuff relates to building with either NPTL or SSL (or both)
enabled. it's just commented out from the previous revision.

if it builds with USE=ssl then you'll be fine. that's all thats really needed.

MySQL with NPTL is not supported by upstream MySQL anyway (but lots of users
want it).

the bug for the mysql automake stuff is bug #45177.

It works fine with USE="ssl" on Alpha. Marked stable.

Worked on s390 with USE="ssl", marked as stable

Stable on sparc.

Stable on AMD64 and x86.

Still waiting on ppc to mark stable to issue the GLSA and/or close this one.
-K

Stable on hppa.

There appears to be two possible symlink attacks in MySQL scripts :

CAN-2004-0381
The script mysqlbug in MySQL allows local users to overwrite arbitrary files via a symlink attack.

CAN-2004-0388
The script mysqld_multi in MySQL allows local users to overwrite arbitrary files via a symlink attack.

Robin : could you include a fixed mysqld_multi in 4.0.18-r1 ? Here is Debian's patch :

--- mysql-dfsg-4.0.18.orig/scripts/mysqld_multi.sh
+++ mysql-dfsg-4.0.18/scripts/mysqld_multi.sh
@@ -9,7 +9,7 @@
 $opt_config_file   = undef();
 $opt_example       = 0;
 $opt_help          = 0;
-$opt_log           = "/tmp/mysqld_multi.log";
+$opt_log           = "$ENV{HOME}/mysqld_multi.log";
 $opt_mysqladmin    = "@bindir@/mysqladmin";
 $opt_mysqld        = "@libexecdir@/mysqld";
 $opt_no_log        = 0;

Thanks

Koon:
would setting $opt_log in mysqld_multi to /var/log/mysql/mysqld_multi.log be acceptable? Arbitary users don't have access there, so that should resolve the security issue and clean things up some.

Robin : I am not sure. 
The $opt_log is the mysqld_multi commands results log, not the mysqld log. I could be wrong, but it seems to me that mysqld_multi is designed so that it can be called with ordinary user rights (if you provide it with accessible TCP port and data/log directories), hence the $HOME thing.
However, if you think it should be called only as root, you decide : your patch would in this case offer the needed security. If you want my opinion, I think user-based logging handles more cases and therefore is better.

Koon:
mysqld_multi needs to be run as root
as it runs each of the child mysqld processes as different users.
i've back-ported the fix from 4.0.19 and i'm putting it in as 4.0.18-r2 very shortly (After i'm sure that 4.0.19 builds as well).

Koon: ok, both 4.0.18-r2 and 4.0.19 are in the cvs tree now.

Perfect !
ppc, mips, ia64 : please mark 4.0.18-r2 or 4.0.19 stable so we can close this one

*BUMP*
ppc, mips, ia64 : please mark >=4.0.18-r2 stable so we can send the GLSA on this one.

mips is done, just had to check the berkdb thing out some more.

In fact ppc marked stable... this one is GLSA-ready.

GLSA 200405-20