MySQL is susceptible to a query-logging-bypass vulnerability. This issue is due to a discrepency between the handling of NULL bytes in input data. (www.securityfocus.com/bid/16850) This issue affects at least <=4.1.14 and <=5.0.18 mysql_connect(...); $result = mysql_query('/*'.chr(0).'*/ SELECT * FROM table'); $result2 = mysql_query('SELECT * FROM table'); it affects my system (4.1.14) 13 Query /* in place of 13 Query select * from table it provides to PHP the same results in $result than in $result2.
*** Bug 128714 has been marked as a duplicate of this bug. ***
i can't CC the herd : <maintainer> <email>mysql_bugs@gentoo.org</email> <description>MySQL herd will not have a mysql@gentoo.org email</description> </maintainer> RCPT TO:<mysql_bugs@gentoo.org> 550 unknown user
Should we correct the metadata in order to publish "mysql-bugs" and not "mysql_bugs"(@gentoo.org) ?
this is http://bugs.mysql.com/bug.php?id=17667 are the latest stable and unstable (~arch) versions affected? mysql team, pls verify/comment/update/...
Hi, upstream have corrected the bug : http://bugs.mysql.com/bug.php?id=17667 For mysql-4.1.14, i've adapted a patch from http://lists.mysql.com/commits/4523 It works for me (compiles, runs and logs as expected) on x86, last stable (4.1.14) I attach the patch here for gentoo mysql-4.1.14 Mysql team, could you please review the patch and then provide a new ebuild, if it is OK for you. Thanks
Created attachment 84240 [details, diff] Patch adapted from upstream for mysql-4.1.14
Many thanks Raphael, Chtekk is absorbed from real-life [tm] this we so I've added some work to what he started. Current status: MySQL 4.1.14, 4.1.18, 5.0.19 fixed and ready to test. MySQL 4.0.x, 5.0 <19, 5.1.x are broken. 4.1.18 and 5.0.19 drop support for mysql_client_test.c, it should be easy enough to make it work again. Personally I've done the testing over slotted MySQL, the plain one is still virgin but all the patches are there. On my system amd64/hardened both 4.1 and 5.0 are not vulnerable any more. The overlay is available at: http://svn.gnqs.org/projects/gentoo-mysql-overlay/browser/ svn co http://svn.gnqs.org/svn/gentoo-mysql-overlay/ patches are in the overlay but you can fetch them from http://dev.gentoo.org/~vivo/slotted_mysql/mysql-extras-20060409.tar.bz2 (required to build) in replay to #c3, I've fixed also the metadata, sorry
Hi, Thanks Francesco. Can mysql-team put the patches in the official portage tree ? (As i have already said, patch for 4.1.14 (latest stable x86) is OK as for me.)
Committed, I don't have a box where to installa and test 4.1.14 in the exact shape it's in cvs at the moment, _but_ all things that vary with my tests are minor and don't overlap with this patch. Hope it's all good.
We're not done here just yet; reopening :)
Thank you plasmaroo; since it's already in stable tree, it's time to vote on a glsa decision. It's a minor issue but : - mysql is *very* common. - it affects *ALL* mysql distributions and versions around the world, so i tend to vote yes.
I tend to vote NO.
(In reply to comment #9) > Committed, I don't have a box where to installa and test 4.1.14 in the exact > shape it's in cvs at the moment, _but_ all things that vary with my tests are > minor and don't overlap with this patch. Hope it's all good. > Thanks Francesco for your commit, but : on 3 different mirrors we got this : !!! No message digest entry found for file "mysql-extras-20060316.tar.bz2." !!! Most likely a temporary problem. Try 'emerge sync' again later. (...) You may have forbidden to include the MD5 digests in the files/digest-mysql-* (except 5.1.7_beta)
Most likely a temporary problem, I don't have it now. I also tend to vote NO. Let's wait for one more man.
> !!! No message digest entry found for file "mysql-extras-20060316.tar.bz2." Sorry, i forgot to add that it was resolved a few hours ago. Thanks to vivo and other who have worked on bug #129548 , a silly issue concerning the portage cache which fills vars when they are left empty.
this vuln is B4 and not A4, because it only affects full log ("log /path/file.log" in /etc/mysql/my.cnf), and not default configuration ("log-bin"). In the binary logs, this vuln can not be exploited. This minimizes the score of the vuln. I'm not sure i'm votting "yes" anymore :) So we have two full "No". Let's close the bug without glsa, if someone disagrees, feel free to reopen. Thanks to mysql team and particulary vivo
