"Security Fix: Using RENAME TABLE against a table with explicit DATA DIRECTORY and INDEX DIRECTORY options can be used to overwrite system table information by replacing the symbolic link points. the file to which the symlink points. MySQL will now return an error when the file to which the symlink points already exists. (Bug#32111, CVE-2007-5969)" This is fixed in the following releases: MySQL Enterprise 5.0.52 http://dev.mysql.com/doc/refman/5.0/en/releasenotes-es-5-0-52.html MySQL Community Server 5.0.51 http://dev.mysql.com/doc/refman/5.0/en/releasenotes-cs-5-0-51.html The changeset itself is probably this (thanks, Vincent!): http://lists.mysql.com/commits/37835 The Enterprise edition also features these entries in ChangeLog: "Security Fix: ALTER VIEW retained the original DEFINER value, even when altered by another user, which could allow that user to gain the access rights of the view. Now ALTER VIEW is allowed only to the original definer or users with the SUPER privilege. (Bug#29908) Security Fix: When using a FEDERATED table, the local server can be forced to crash if the remote server returns a result with fewer columns than expected. (Bug#29801)" Bumping discussion can be found at bug 187817. Mysql, please advise how to proceed and if you consider the last two issues worth fixing.
The RENAME TABLE issue needs fixing, I'll see about backporting the patch, since the latest upstream releases are in a bad state wrt failing their tests - Debian has confirmed they fail the tests in their environment too, so it's not Gentoo-specific. ALTER VIEW and the FEDERATED crash I don't see as major issues: VIEWs have low uptake and you'd need privileges to alter the view anyway; FEDERATED has an even smaller uptake, and is also advertised as experimental by upstream (there are other ways to remotely crash it).
CVE identifiers were assigned to the last two issues. When merging patches, please try to include CVE-2007-6303, as it allows escalation of privileges, even if only in marginal cases. I agree with your assessment of CVE-2007-6304, no need to fix features that are marked experimental. CVE-2007-6303: MySQL 5.0.x before 5.0.52, 5.1.x before 5.1.23, and 6.0.x before 6.0.4 does not update the DEFINER value of a view when the view is altered, which allows remote authenticated users to gain privileges via a sequence of statements including a CREATE SQL SECURITY DEFINER VIEW statement and an ALTER VIEW statement. CVE-2007-6304: The federated engine in MySQL 5.0.x before 5.0.52, 5.1.x before 5.1.23, and 6.0.x before 6.0.4, when performing a certain SHOW TABLE STATUS query, does not properly handle a response with a small number of columns, which allows remote MySQL servers to cause a denial of service (federated handler crash and daemon crash) via a response that lacks the minimum required number of columns.
These two CVEs might also need to be taken into account ? [CVE-2007-5969]: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5969 "MySQL Community Server before 5.0.51, when a table relies on symlinks created through explicit DATA DIRECTORY and INDEX DIRECTORY options, allows remote authenticated users to overwrite system table information and gain privileges via a RENAME TABLE statement that changes the symlink to point to an existing file." [CVE-2007-5970]: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5970 "MySQL 5.1.x before 5.1.23 and 6.0.x before 6.0.4 allows remote authenticated users to gain privileges on arbitrary tables via unspecified vectors involving use of table-level DATA DIRECTORY and INDEX DIRECTORY options when creating a partitioned table with the same name as a table on which the user lacks privileges."
bernd: did you actually read the summary line, or the first post in the bug, which have the identical CVE-2007-5969? ETA for my backported patch is Sunday.
(In reply to comment #3) > [CVE-2007-5970]: > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5970 > > "MySQL 5.1.x before 5.1.23 and 6.0.x before 6.0.4 allows remote authenticated > users to gain privileges on arbitrary tables via unspecified vectors involving > use of table-level DATA DIRECTORY and INDEX DIRECTORY options when creating a > partitioned table with the same name as a table on which the user lacks > privileges." This only affects MySQL 5.1.x which we do not ship for Enterprise and which is p.masked for community.
Created attachment 138867 [details, diff] CVE-2007-5969.dpatch
Created attachment 138868 [details, diff] CVE-2007-6303.patch
Created attachment 138869 [details, diff] CVE-2007-6304.patch
The above patches stolen from Debian, who researched the relevant commits. Hopefully that might save you some time. I refreshed them to apply to 5.0.44-r2 cleanly. Oh, and I forgot to change the file ending of the first one :-/
ping
5.0.54 is in the tree which will resolve this. It's pmasked at the moment, pending more testing, please see my comment on bug 187817 as to why I was delayed.
*** Bug 206156 has been marked as a duplicate of this bug. ***
Robin, should I call arches to test on this bug or will you notify when it's ready?
rbu: please hold on still. there's some post-5.0.54 patches that I'm going to put into the the ebuild, one of which has security implications, and the other fixes a bad performance regression: http://bugs.mysql.com/bug.php?id=27440 http://bugs.mysql.com/bug.php?id=33057
Back to ebuild then. "rbu" over and out :)
Would the real rbu please stand up!
5.0.54 is ready for arch testing. cvs up, make sure the mysql-extras is dated 20080124. Testing procedures: -------------------- cvs up FEATURES='test userpriv' USE='test berkdb perl ssl cluster embedded extraengine' ebuild mysql-5.0.54.ebuild test Notes to arches: ---------------- - archive_gis disabled on big-endian for failures. - read_only disabled for side effect of fixing upstream 27440. Notes to security: ------------------ Upstream bug 27440 is probably GLSA worth as well, but I haven't seen any vendor announcements about it. Specifically, it allows mysql users to issue 'DROP DATABASE' without having the 'SUPER' privilege when the database is configured as read-only (common with database slaves).
Thx Robin. Arches please test and mark stable. Target keywords are: mysql-5.0.54.ebuild:KEYWORDS="alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc ~sparc-fbsd x86 ~x86-fbsd" @release welcome to sec arch testing :-)
I get several test failures on x86 with different sets of USE flags. Now some links to the packed up /var/tmp/portage/dev-db/mysql-5.0.54 directory. www.v-li.de/temp/mysql-5.0.54-failing-tests.tar.bz2 (all USE flags except static and debug) www.v-li.de/temp/mysql-5.0.54-failing-tests-2.tar.bz2 (none) www.v-li.de/temp/mysql-5.0.54-failing-tests-3.tar.bz2 (some) Give the last one some time to be uploaded completely. They are huge, by the way. Portage 2.1.3.19 (default-linux/x86/2007.0/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.23-gentoo-r6 i686) ================================================================= System uname: 2.6.23-gentoo-r6 i686 AMD Athlon(tm) X2 Dual Core Processor BE-2400 Timestamp of tree: Fri, 25 Jan 2008 11:16:01 +0000 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.0.33-r1 dev-lang/python: 2.4.4-r6 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.10-r5 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /opt/openfire/resources/security/ /opt/openjms/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/lib/hsqldb /var/qmail/alias /var/qmail/control /var/vpopmail/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch userpriv" GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo/" LANG="de_DE.utf8" LC_ALL="de_DE.utf8" LINGUAS="de" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/sunrise" SYNC="rsync://rsync.informatik.rwth-aachen.de/gentoo-portage" USE="3dnow 3dnowext X a52 acl acpi aiglx alsa apache2 apm applet artworkextra asf audiofile avahi bash-completion beagle berkdb bidi bitmap-fonts bogofilter bootsplash branding bzip2 cairo ccache cdda cddb cdparanoia cdr cli console cracklib crypt css cups curl custom-cflags dbus dga directfb divx4linux dri dts dvd dvdr dvdread dvi eds emacs emboss encode esd evince evo exif fam fat fbcon fdftk ffmpeg firefox flac foomaticdb fortran ftp gb gcj gdbm gif glitz gnome gpm gsf gstreamer gtk gtk2 gtkhtml hal howl iconv icq idn imagemagick imap imlib immqt-bc isdnlog java javascript jpeg jpeg2k kde ldap libnotify lirc lm_sensors mad maildir matroska mbox midi mikmod mime mmx mmxext mng mono mp3 mpeg mpeg2 mudflap mule mysql nautilus ncurses nforce2 nls nocardbus nptl nptlonly nsplugin nvidia objc objc++ objc-gc offensive ogg opengl openmp pam pango pcre pdf perl php plotutils pmu png ppds pppd prediction preview-latex print python qt3 qt3support qt4 quicktime readline reflection samba sdk session slang spell spl sse ssl svg svga t1lib tcl tcpd tetex theora threads thumbnailing tiff tk toolkit-scroll-bars totem tracker truetype truetype-fonts type1-fonts udev unicode usb userlocales vcd videos vorbis win32codecs wmf wxwindows x86 xface xft xine xml xorg xosd xpm xv xvid zlib" ALSA_CARDS="intel8x0" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CAMERAS="canon ptp2" ELIBC="glibc" INPUT_DEVICES="mouse keyboard" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de" LIRC_DEVICES="atiusb" USERLAND="GNU" VIDEO_CARDS="vesa fbdev fglrx" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
This does build and work on sparc for me. However, I'd like to see some response to Comment 19 before marking it.
opfer: can you please attach/upload the actual ebuild test output as well? I think something is wrong with your box at a glance, given that you got different test failures. Which of the 3 sets of output corresponds to the USE flags that I gave in my instructions? (You should generally not set big-tables, latin1, max-idx-128 unless you have a very specific need for them). pass1: create, ps_1general, ps_2myisam, ps_3innodb, ps_4heap, ps_5merge, ps_6bdb, ps_7ndb, subselect pass2: subselect pass3: subselect I originally tested on amd64 and ppc64-32ul before I committed (with no errors at all), but I'll test on an x86 box next and report back here.
I'm getting fails on amd64. However, I get most of the same fails on the current stable version. Only ndb_bug26793 is a new failure. I tested using the command suggested in comment 17. Note that the test phase is expected to fail with paludis due to reliance on the FEATURES environment variable unless you export FEATURES=userpriv (bug 187024). Failed 45/481 tests, 90.64% were successful. The log files in var/log may give you some hint of what went wrong. If you want to report this error, please read first the documentation at http://dev.mysql.com/doc/mysql/en/mysql-test-suite.html The servers were restarted 102 times Spent 521.944 of 1177 seconds executing testcases mysql-test-run in ps-protocol mode: *** Failing the test(s): loaddata_autocom_ndb ndb_alter_table ndb_alter_table2 ndb_autodiscover ndb_autodiscover2 ndb_autodiscover3 ndb_basic ndb_bitfield ndb_blob ndb_bug26793 ndb_cache ndb_cache2 ndb_cache_multi ndb_cache_multi2 ndb_charset ndb_condition_pushdown ndb_config ndb_database ndb_gis ndb_index ndb_index_ordered ndb_index_unique ndb_insert ndb_limit ndb_load ndb_loaddatalocal ndb_lock ndb_minmax ndb_multi ndb_read_multi_range ndb_rename ndb_replace ndb_restore ndb_restore_different_endian_data ndb_restore_print ndb_single_user ndb_subquery ndb_transaction ndb_trigger ndb_truncate ndb_types ndb_update ps_7ndb rpl_ndb_innodb_trans strict_autoinc_5ndb
rich0: Could you tar up your ${S} and post it online for me?
(In reply to comment #22) > I'm getting fails on amd64. However, I get most of the same fails on the > current stable version. Only ndb_bug26793 is a new failure. I tested using > the command suggested in comment 17. Note that the test phase is expected to > fail with paludis due to reliance on the FEATURES environment variable unless > you export FEATURES=userpriv (bug 187024). > > Failed 45/481 tests, 90.64% were successful. > > The log files in var/log may give you some hint > of what went wrong. > If you want to report this error, please read first the documentation at > http://dev.mysql.com/doc/mysql/en/mysql-test-suite.html > The servers were restarted 102 times > Spent 521.944 of 1177 seconds executing testcases > > mysql-test-run in ps-protocol mode: *** Failing the test(s): > loaddata_autocom_ndb ndb_alter_table ndb_alter_table2 ndb_autodiscover > ndb_autodiscover2 ndb_autodiscover3 ndb_basic ndb_bitfield ndb_blob > ndb_bug26793 ndb_cache ndb_cache2 ndb_cache_multi ndb_cache_multi2 ndb_charset > ndb_condition_pushdown ndb_config ndb_database ndb_gis ndb_index > ndb_index_ordered ndb_index_unique ndb_insert ndb_limit ndb_load > ndb_loaddatalocal ndb_lock ndb_minmax ndb_multi ndb_read_multi_range ndb_rename > ndb_replace ndb_restore ndb_restore_different_endian_data ndb_restore_print > ndb_single_user ndb_subquery ndb_transaction ndb_trigger ndb_truncate ndb_types > ndb_update ps_7ndb rpl_ndb_innodb_trans strict_autoinc_5ndb > I see similar failures with ndb-related tests on sparc. Since they are the same tests, I suspect they are the same failure.
fmccor: in comment 20, you said it worked for you, and mentioned nothing about test failures. Now in comment 24, you claim to see the same ndb failures. On my x86 box where I ran the tests now, the subselect testcase did fail, I'm looking into why - I suspect a patch that was supposed to fix a stack issue with s390, because of this output: 1436: Thread stack overrun: 163904 bytes used of a 196608 byte stack, and 32768 bytes needed. Use 'mysqld -O thread_stack=#' to specify a bigger stack.
(In reply to comment #21) > opfer: can you please attach/upload the actual ebuild test output as well? You mean the log files? Actually I did not test with your exact set...will do so now. http://www.v-li.de/temp/mysql-5.0.54-logs.tar.bz2
Ok, for subselect, looks like upstream knows the testcase is broken, they just don't allocate enough stack in the testcase presently for x86. The code itself is ok. I've disabled the subselect testcase on x86 for that now, so it's just to see why opfer got the other ps_* failures on one pass, and why other folk are getting the ndb failures.
opfer: ok, all of your ps_* failures were because you passed in USE=big-tables/ max-idx-128. Just side effects of those showing the files on disk being larger (so the expected sizes don't match). That leaves just the ndb_* failures mentioned, when that tarball is linked here by rich0 or fmccor?
(In reply to comment #28) > opfer: ok, all of your ps_* failures were because you passed in USE=big-tables/ > max-idx-128. Just side effects of those showing the files on disk being larger > (so the expected sizes don't match). Thanks for making that clear. x86 stable then.
(In reply to comment #25) > fmccor: in comment 20, you said it worked for you, and mentioned nothing about > test failures. Now in comment 24, you claim to see the same ndb failures. > > On my x86 box where I ran the tests now, the subselect testcase did fail, I'm > looking into why - I suspect a patch that was supposed to fix a stack issue > with s390, because of this output: > 1436: Thread stack overrun: 163904 bytes used of a 196608 byte stack, and > 32768 bytes needed. Use 'mysqld -O thread_stack=#' to specify a bigger stack. > Sorry, my statement was someplace between unclear and misleading. By "worked" I meant that it installs and handles my databases. I had put off the actual FEATURES=test tests, because they take forever to run and opfer was reporting failures. I wanted to know what the response to those was before starting the actual official test. Later, the system was available for the extended tests, so I started them and noticed the same failures that Richard reports. So I just noted that in case it might be helpful. I shouldn't have reported sparc status at all, I suppose, until I was finished testing and I apologize for any confusion. I just thought that the fact that mysql could handle my databases as expected, at least, might be a useful pice of information. My mistake; I won't do it again.
fmccor: I'm still interested in what those failures were, to see if they were false negatives like opfer's ones.
(In reply to comment #23) > rich0: Could you tar up your ${S} and post it online for me? > Sure. For the current stable version: http://gw.thefreemanclan.net:8765/share/mysql-5.0.44-r2.tbz2 For the 5.0.54 version: http://gw.thefreemanclan.net:8765/share/mysql-5.0.54.tbz2 If for whatever reason you can't use that odd port https to the same address works fine as well - port 80 outgoing is unfortunately blocked for me. In case you don't want to download that whole thing I also unpacked them all in the /share directory - you can browse at will and download what you what...
alpha/ia64 stable
ppc stable
(In reply to comment #31) > fmccor: I'm still interested in what those failures were, to see if they were > false negatives like opfer's ones. > My guess is something with the USE flags. The version I reported as working for my databases had installed normally as part of a mysql update (I run mysql as ~sparc), and the upgrade occurred normally before I had seen this request. The 'eix' for that version is: ============================= [I] dev-db/mysql Available versions: [M]3.23.58-r1 4.0.27-r1 4.1.22-r1 [M](~)4.1.23_alpha20070101-r61 5.0.26-r2 (~)5.0.32 (~)5.0.34 5.0.38 5.0.40 5.0.42 (~)5.0.44 5.0.44-r1 5.0.44-r2 (~)5.0.54 {berkdb big-tables cluster debug embedded extraengine innodb latin1 max-idx-128 minimal perl raid readline selinux ssl static tcpd} Installed versions: 5.0.54(06:16:38 PM 01/25/2008)(perl ssl -berkdb -big-tables -cluster -debug -embedded -extraengine -latin1 -max-idx-128 -minimal -selinux -static) Homepage: http://www.mysql.com/ Description: A fast, multi-threaded, multi-user SQL database server. ===================================== I never use USE=berkdb because at one time at least, it was believed bad (or bad on sparc). When later I ran the full test as described in Comment 17, I ran it exactly as mentioned there, so it also had USE='berkdb cluster test extraengine ...' set. Thus, when running the official test, there were USE flags set which I have never used on sparc and have no idea if they are good on sparc. That is, the version I said could handle my applications was built in my production environment, and is built to handle that environment. The one used for testing used USE= values I have never set. In the test environment, I saw exactly the same failures as Richard did on amd64 --- ndb tests (or tests using ndb) systematically failed, although generally mysql tested as good (which I had expected because I knew it processed my databases as it should). My uninformed guess is that given the name of the failures and the fact that I "knew" USE=berkdb was problematic, the problem is somehow related to berkdb. Other possibility is related to USE=cluster.
ppc64 stable
I suspect the test errors are probably a false indication. I'll do some informal testing. If the consensus around here is that the test fails aren't a problem I don't see why this can't go stable on amd64 - but I'm a new dev and considering the nature of mysql I figured I'd be cautious. I'll do some more testing, and if anybody else on the amd64 team thinks this is safe to go stable feel free to keyword it before then...
rich0/fmccor: on your test boxes, do you have some firewall that blocks localhost traffic? The logs from rich0's attachment say that it failed to start up the NDB cluster bootstrap, and the detailed logs show that the processes started, but the master could not contact them: Connecting to mgmsrv at host=localhost:10265 State node 1 NO_CONTACT State node 2 NO_CONTACT Waiting for cluster enter state STARTED ... waitNodeState(STARTED, -1) timeout after 61 attempts
(In reply to comment #38) > rich0/fmccor: on your test boxes, do you have some firewall that blocks > localhost traffic? > I'm running shorewall, but that shouldn't block local traffic (at least it doesn't in my experience and the policies look ok to me). Can you think of a quick way to test this? In all my informal testing everything works fine, and it passed the test suite with my normal USE flags. However, I don't have a serious installation (clustering/etc).
rich0: Here's a testcase. # emerge netcat # netcat -l -p 10265 -s 127.0.0.1 (then, in seperate terminal, same box) # echo foo >/dev/tcp/127.0.0.1/10265 You should see 'foo' in the netcat window. If you don't, run the following two lines, and repeat the above test. iptables -I INPUT 1 -i lo -j ACCEPT iptables -I OUTPUT 1 -o lo -j ACCEPT
The foo got through just fine (substituting nc for netcat...). So it isn't the firewall. Considering that I get the exact same errors on the current stable version of mysql and it has been working for a day without issue I'm guessing we should just mark .54 stable to resolve the security issue - unless you suspect that this is going to break production systems (although anybody doing anything serious should be doing their own testing anyway). I'm not sure what the impact of these tests really is.
weird. yeah, go ahead and mark stable for now. anybody into MySQL deep enough to be using NDB should really be doing their own testing (and it does pass NDB testing on my boxes, so meh)
amd64 stable - thanks for the investigation effort
Sparc stable, based on (1) This is a security bug; (2) This version works fine for me as part of a normal upgrade; (3) other comments on this bug. I'm CC-ing myself to monitor.
Stable for HPPA.
This bug does not affect 2008.0 release snaphost, removing release@ from CC.
rbu: why'd you change the vuln versions?
(In reply to comment #47) > rbu: why'd you change the vuln versions? Because the bugs usually refer to ebuilds in the tree. 5.0.52 never had an ebuild committed, so 5.0.54 was the first version not vulnerable to this (in Gentoo). This is also how it will be mentioned in the GLSA (which is to be sent soon).
.52 wasn't in the public tree because upstream broke it, but the ebuild did exist for the folks that helped me test it via an overlay. But if you're going to mention it in the GLSA, it should be ok.
GLSA 200804-04. mysql-community was also fixed per: * CVE-2007-5969 5.0.51 * CVE-2007-6303 5.0.51a * CVE-2007-6304 5.0.51a 5.1 is masked and therefore not subject to security support.
