Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 201669 - dev-db/mysql < 5.0.54 dev-db/mysql-community <5.0.51a RENAME TABLE system table replace (CVE-2007-{5969,6303,6304})
Summary: dev-db/mysql < 5.0.54 dev-db/mysql-community <5.0.51a RENAME TABLE system tab...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Security
URL: http://lists.mysql.com/commits/37835
Whiteboard: A3 [glsa]
Keywords:
: 206156 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-12-08 14:10 UTC by Robert Buchholz (RETIRED)
Modified: 2011-10-20 04:58 UTC (History)
7 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
CVE-2007-5969.dpatch (CVE-2007-5969.dpatch,2.59 KB, patch)
2007-12-19 02:46 UTC, Robert Buchholz (RETIRED)
no flags Details | Diff
CVE-2007-6303.patch (CVE-2007-6303.patch,6.55 KB, patch)
2007-12-19 02:47 UTC, Robert Buchholz (RETIRED)
no flags Details | Diff
CVE-2007-6304.patch (CVE-2007-6304.patch,556 bytes, patch)
2007-12-19 02:47 UTC, Robert Buchholz (RETIRED)
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Buchholz (RETIRED) gentoo-dev 2007-12-08 14:10:41 UTC
"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.
Comment 1 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2007-12-08 22:06:34 UTC
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).
Comment 2 Robert Buchholz (RETIRED) gentoo-dev 2007-12-12 00:14:32 UTC
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.
Comment 3 Bernd Marienfeldt 2007-12-13 11:40:59 UTC
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."


Comment 4 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2007-12-13 11:49:42 UTC
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.
Comment 5 Robert Buchholz (RETIRED) gentoo-dev 2007-12-13 12:25:14 UTC
(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.

Comment 6 Robert Buchholz (RETIRED) gentoo-dev 2007-12-19 02:46:39 UTC
Created attachment 138867 [details, diff]
CVE-2007-5969.dpatch
Comment 7 Robert Buchholz (RETIRED) gentoo-dev 2007-12-19 02:47:07 UTC
Created attachment 138868 [details, diff]
CVE-2007-6303.patch
Comment 8 Robert Buchholz (RETIRED) gentoo-dev 2007-12-19 02:47:20 UTC
Created attachment 138869 [details, diff]
CVE-2007-6304.patch
Comment 9 Robert Buchholz (RETIRED) gentoo-dev 2007-12-19 02:49:04 UTC
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 :-/
Comment 10 Robert Buchholz (RETIRED) gentoo-dev 2008-01-05 02:45:50 UTC
ping
Comment 11 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-01-15 15:29:23 UTC
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.
Comment 12 Jakub Moc (RETIRED) gentoo-dev 2008-01-16 21:41:57 UTC
*** Bug 206156 has been marked as a duplicate of this bug. ***
Comment 13 Sune Kloppenborg Jeppesen gentoo-dev 2008-01-17 16:06:26 UTC
Robin, should I call arches to test on this bug or will you notify when it's ready?
Comment 14 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-01-17 19:55:43 UTC
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
Comment 15 Sune Kloppenborg Jeppesen gentoo-dev 2008-01-17 20:03:11 UTC
Back to ebuild then.

"rbu" over and out :)
Comment 16 Robert Buchholz (RETIRED) gentoo-dev 2008-01-19 23:51:32 UTC
Would the real rbu please stand up!
Comment 17 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-01-25 08:57:46 UTC
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).
Comment 18 Sune Kloppenborg Jeppesen gentoo-dev 2008-01-25 09:59:35 UTC
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 :-)
Comment 19 Christian Faulhammer (RETIRED) gentoo-dev 2008-01-25 16:16:59 UTC
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
Comment 20 Ferris McCormick (RETIRED) gentoo-dev 2008-01-25 18:47:23 UTC
This does build and work on sparc for me.  However, I'd like to see some response to Comment 19 before marking it.
Comment 21 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-01-25 19:30:52 UTC
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.
Comment 22 Richard Freeman gentoo-dev 2008-01-25 21:52:27 UTC
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
Comment 23 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-01-25 21:59:46 UTC
rich0: Could you tar up your ${S} and post it online for me?
Comment 24 Ferris McCormick (RETIRED) gentoo-dev 2008-01-25 22:17:54 UTC
(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.
Comment 25 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-01-25 22:26:09 UTC
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.
Comment 26 Christian Faulhammer (RETIRED) gentoo-dev 2008-01-25 22:37:14 UTC
(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
Comment 27 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-01-25 22:55:48 UTC
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.
Comment 28 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-01-25 23:11:23 UTC
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? 
Comment 29 Christian Faulhammer (RETIRED) gentoo-dev 2008-01-25 23:17:31 UTC
(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.
Comment 30 Ferris McCormick (RETIRED) gentoo-dev 2008-01-25 23:19:09 UTC
(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.  
Comment 31 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-01-25 23:22:37 UTC
fmccor: I'm still interested in what those failures were, to see if they were false negatives like opfer's ones.
Comment 32 Richard Freeman gentoo-dev 2008-01-26 02:52:39 UTC
(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...
Comment 33 Raúl Porcel (RETIRED) gentoo-dev 2008-01-26 10:47:44 UTC
alpha/ia64 stable
Comment 34 Tobias Scherbaum (RETIRED) gentoo-dev 2008-01-26 13:08:13 UTC
ppc stable
Comment 35 Ferris McCormick (RETIRED) gentoo-dev 2008-01-26 14:08:58 UTC
(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.
Comment 36 Brent Baude (RETIRED) gentoo-dev 2008-01-26 14:25:11 UTC
ppc64 stable
Comment 37 Richard Freeman gentoo-dev 2008-01-26 15:07:11 UTC
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...
Comment 38 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-01-26 22:09:08 UTC
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

Comment 39 Richard Freeman gentoo-dev 2008-01-26 23:08:42 UTC
(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).  
Comment 40 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-01-26 23:15:44 UTC
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
Comment 41 Richard Freeman gentoo-dev 2008-01-27 14:16:28 UTC
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.
Comment 42 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-01-27 14:22:20 UTC
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)
Comment 43 Richard Freeman gentoo-dev 2008-01-27 14:26:50 UTC
amd64 stable - thanks for the investigation effort
Comment 44 Ferris McCormick (RETIRED) gentoo-dev 2008-01-27 19:07:33 UTC
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.
Comment 45 Jeroen Roovers gentoo-dev 2008-01-28 07:05:46 UTC
Stable for HPPA.
Comment 46 Peter Volkov (RETIRED) gentoo-dev 2008-02-25 10:56:08 UTC
This bug does not affect 2008.0 release snaphost, removing release@ from CC.
Comment 47 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-04-03 23:55:38 UTC
rbu: why'd you change the vuln versions?
Comment 48 Robert Buchholz (RETIRED) gentoo-dev 2008-04-04 00:05:36 UTC
(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).
Comment 49 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-04-04 00:42:23 UTC
.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.
Comment 50 Robert Buchholz (RETIRED) gentoo-dev 2008-04-06 13:27:16 UTC
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.