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

CC: (none) => luigiwalser

Four patches were added in Mageia 2 SVN:
- mariadb-5.5-mdev4029.patch
- mariadb-5.5-CVE-2012-5627.patch
- mariadb-5.5-buffer-overflow.patch
- mariadb-5.5-CVE-2012-5615.patch

For MySQL in Mageia 1, I tried adding those patches.

The first one applied cleanly (mdev4029)

The next two needed minor rediffing, then applied (CVE-2012-5627, buffer-overflow)

The last one needed major rediffing work, then still didn't work because of too many code changes.  I don't know the code well enough to finish backporting it.

So, the first three patches are in Mageia 1 SVN.

Is this one ready for testing?

Yes.  My comment about the Mageia 1 MySQL package are irrelevant for this Mageia 2 MariaDB update.  It's been ready to test since this bug was filed.

PoC's: CVE-2012-5627/MDEV-3915: http://seclists.org/fulldisclosure/2012/Dec/58
       CVE-2012-5615/MDEV-3909: http://seclists.org/fulldisclosure/2012/Dec/9

SRPM: mariadb-5.5.25-2.6.mga2.src.rpm
-------------------------------------
libmariadb18
libmariadb-devel
libmariadb-embedded18
libmariadb-embedded-devel
mariadb-bench
mariadb-client
mariadb-common-core
mariadb-common
mariadb-core
mariadb-debug
mariadb-extra
mariadb-feedback
mariadb
mariadb-obsolete
mysql-MariaDB

Testing mga2 32

Before
------
# mysql -u root -p
Enter password:

MariaDB [(none)]> CREATE USER 'crackme'@'localhost' IDENTIFIED BY 'pass';
MariaDB [(none)]> CREATE USER 'user'@'localhost' IDENTIFIED BY 'secret';
MariaDB [(none)]> CREATE DATABASE test;
MariaDB [(none)]> grant select, insert, delete on test.* to 'user'@'localhost';
MariaDB [(none)]> FLUSH PRIVILEGES;
MariaDB [(none)]> quit;
Bye

# urpmi perl-Net-MySQL

Edit /etc/my.cnf and comment out skip-networking by putting a # in front of it and restart the service. Edit mysqlcrack.pl and change the hostname variable to localhost at the top.

# systemctl restart mysqld.service

$ john --incremental --stdout=5 | perl mysqlcrack.pl
Warning: MaxLen = 8 is too large for the current hash type, reduced to 5
[*] Cracked! --> pass

Confirmed vulnerable to CVE-2012-5627

$ wget -O mysql_userenum.pl http://seclists.org/fulldisclosure/2012/Dec/att-9/mysql_userenum_pl.bin

$ echo -e "wrong1\nwrong2\nwrong3\nwrong4\nuser\nwrong5\nwrong6\n" > wordlist.txt

# urpmi perl-Parallel-ForkManager

$ perl mysql_userenum.pl localhost wordlist.txt

[*] HIT! -- USER EXISTS: user@localhost

Confirmed vulnerable to CVE-2012-5615


After
-----
# systemctl restart mysqld.service

$ perl mysql_userenum.pl localhost wordlist.txt
Warning: MaxLen = 8 is too large for the current hash type, reduced to 5
words: 13725  time: 0:00:03:54 0.00%  w/s: 58.42  current: ance
Session aborted

Killed after a few minutes with ctrl-c (yes it's an old laptop :P).
Confirmed fixed CVE-2012-5627

$ perl mysql_userenum.pl localhost wordlist.txt

[*] HIT! -- USER EXISTS: user@localhost

So the patch doesn't seem to fix CVE-2012-5615. Added 'crackme' to the wordlist too and it finds that one also.

Whiteboard: (none) => feedback

Mis-paste above, should have been.

$ john --incremental --stdout=5 | perl mysqlcrack.pl
Warning: MaxLen = 8 is too large for the current hash type, reduced to 5
words: 13725  time: 0:00:03:54 0.00%  w/s: 58.42  current: ance
Session aborted

Running john for quite a bit longer finishes at exactly the same point (13725 ance), strangely, guessing it now limits the incorrect attempts.

did you also run:

cd /usr/share/mysql/mysql-test && ./mysql-test-run.pl failed_auth_3909

which should be the test to fix CVE-2012-5615 ...

that particular test fails, but only due to unrelated changes.

There was a separate patch which fixed this some test cases where NO was reported instead of YES; and the error string changed in another patch.

in backporting the patch, i should've checked it first and corrected the expected results accordingly; but they are non-critical.

I talked to upstream about this, and due to fixing, the exploit isn't working properly anymore and also reports some nonexisting users as existing as well.

I've submitted mariadb-5.5.25-2.7.mga2 for update testing.

this also fixes the failed_auth_3909 test and disables adding anonymous user by default, which in certain cases with certain configuration would still be exploitable with CVE-2012-5615.



Addendum to advisory:
---------------------

Be advised that for CVE-2012-5615 to be completely closed, it's recommended to remove any anonymous logins. previously, such a user without access rights w

as added by default.

oops, i submitted between comment by accident

Testing mga2 64

Using a VM with lxde so I can start without any mariadb installed and installing the testing version directly.

$ rpm -qa | grep -i -e mysql -e maria
$

Installed from updates testing

# urpmi mariadb-bench mariadb-client mariadb-common-core mariadb-common mariadb-core mariadb-extra mariadb mariadb-obsolete mysql-MariaDB lib64mariadb18 lib64mariadb-embedded18

# service mysqld start
Starting mysqld (via systemctl):                                [  OK  ]
# mysqladmin password
New password: 
Confirm new password: 

# mysql -u root -p
Enter password: 

MariaDB [(none)]> select user,host,length(password) from mysql.user;
+------+-----------+------------------+
| user | host      | length(password) |
+------+-----------+------------------+
| root | localhost |               41 |
| root | 127.0.0.1 |                0 |
| root | ::1       |                0 |
+------+-----------+------------------+
3 rows in set (0.00 sec)

Shows the anonymous user, without password has now gone from the default installation. The patch is valid.

Removed all packages and installed again from Updates to compare the result.
+------+-----------+------------------+
| user | host      | length(password) |
+------+-----------+------------------+
| root | localhost |               41 |
| root | 127.0.0.1 |                0 |
| root | ::1       |                0 |
|      | localhost |                0 |
+------+-----------+------------------+
4 rows in set (0.01 sec)

I'll test the update on an existing installation in a few minutes.

Failed_auth_3909 also passes now

# cd /usr/share/mysql/mysql-test && ./mysql-test-run.pl failed_auth_3909
Logging: ./mysql-test-run.pl  failed_auth_3909
vardir: /usr/share/mysql/mysql-test/var
Removing old var directory...
Creating var directory '/usr/share/mysql/mysql-test/var'...
Checking supported features...
MariaDB Version 5.5.25-MariaDB
Installing system database...
 - skipping ndbcluster
 - SSL connections supported
Collecting tests...
Using server port 46522

==============================================================================

TEST                                      RESULT   TIME (ms) or COMMENT
--------------------------------------------------------------------------

worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 16000..16019
worker[1] mysql-test-run: WARNING: running this script as _root_ will cause some tests to be skipped
main.failed_auth_3909                    [ pass ]   3075
--------------------------------------------------------------------------
The servers were restarted 0 times
Spent 3.075 of 7 seconds executing testcases

Completed: All 1 tests were successful.

Testing complete mga2 64

Updated the host computer and manually removed the anonymous user with phpmyadmin.

Tested with db using things like zoneminder, phpmyadmin

On a Mageia 2 32 bit vb install ...

./mysql-test-run --force
<snip>
Too many tests(10) failed! Terminating...

Only  221  of 2466 completed.
--------------------------------------------------------------------------
The servers were restarted 19 times
Spent 3.542 of 73 seconds executing testcases

Too many failed: Failed 10/23 tests, 56.52% were successful.

Failing test(s): federated.federated_partition federated.federated_transactions federated.federated_innodb rpl.rpl_auto_increment rpl.rpl_invoked_features rpl.rpl_auto_increment_bug45679 rpl.rpl_auto_increment_update_failure rpl.rpl_binlog_grant

CC: (none) => davidwhodgins
Whiteboard: has_procedure mga2-64-OK => has_procedure mga2-64-OK feedback

it is possible that quite some tests fail on some systems, i too have a similar issue when i noticed that the mysql server being started by the test system used a port that was in use by pulseaudio.

i would not like this to be blocking this security update...

we can investigate all the tests at a later date.

Bug 8984 created for the failing testsuite

Are you happy to validate otherwise Dave?

Confirmed the core updates version of mariadb segfaults when running the test
from mariadb-bench on i586 too, so the problems are not a regression.

Validating the update.

Could someone from the sysadmin team push the srpm
mariadb-5.5.25-2.7.mga2.src.rpm
from Mageia 2 Core Updates Testing to Core Updates.

Advisory: This release includes fixes for the following security
vulnerabilities:
* A buffer overflow that can cause a server crash or arbitrary code execution
(a variant of CVE-2012-5611)
* CVE-2012-5627/MDEV-3915 fast password brute-forcing using the "change user"
command
* CVE-2012-5615/MDEV-3909 information leakage about existing user accounts
via the protocol handshake
* in addition it fixes MDEV-4029

References:
https://mariadb.atlassian.net/browse/MDEV-4029
https://mariadb.atlassian.net/browse/MDEV-3915
https://mariadb.atlassian.net/browse/MDEV-3909

Be advised that for CVE-2012-5615 to be completely closed, it's recommended
to remove any anonymous logins. Previously, such a user without access
rights was added by default.

https://bugs.mageia.org/show_bug.cgi?id=8921

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs
Whiteboard: has_procedure mga2-64-OK => has_procedure mga2-64-OK MGA2-32-OK

Dropping validation ad alien has pushed a mariadb-5.5.25-2.8.mga2 to updates_testing

Keywords: validated_update => (none)
CC: (none) => tmb
Source RPM: mariadb-5.5.25-2.7.mga2.src.rpm => mariadb-5.5.25-2.8.mga2.src.rpm
Whiteboard: has_procedure mga2-64-OK MGA2-32-OK => has_procedure

i had no time yet to react, but this second release fixes the last remaining failing test case:

rpl.rpl_mdev382

this was a security issue that didn't full gotten fixed in our build.

i also added the patch that should fix the aio problem that happens during testing.


nothing has changed wrt to the older bugs, so that should be fine.

Testing mga2 64

# cd /usr/share/mysql/mysql-test && ./mysql-test-run.pl

mysqltest: Result length mismatch

 - saving '/usr/share/mysql/mysql-test/var/log/binlog.binlog_row_mysqlbinlog_options-row/' to '/usr/share/mysql/mysql-test/var/log/binlog.binlog_row_mysqlbinlog_options-row/'

Only  816  of 2442 completed.
--------------------------------------------------------------------------
The servers were restarted 292 times
Spent 1469.307 of 2519 seconds executing testcases

Failure: Failed 1/600 tests, 99.83% were successful.

Failing test(s): binlog.binlog_row_mysqlbinlog_options

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

181 tests were skipped, 47 by the test itself.

mysql-test-run: *** ERROR: there were failing test cases

could you give me the detail?

# cd /usr/share/mysql/mysql-test && ./mysql-test-run.pl binlog.binlog_row_mysqlbinlog_options

thanks a lot

ok, can reproduce, and this one is very very strange... (but is actually just the test that fails)

(i've also found some more noncritical ones)

in any case, i would prefer this update not to be blocked by this issue (since these issues are not critical). even though i will likely do an update later that will fix more tests.


so, the problem here is that there's a helpfile called loaddata7.dat for this test. and this file is really only:

2,2
3,3
4,4
5,5
6,6

except that the line endings are \r\n aka CRLF aka DOS line endings.

now, this file is inside the tarball from upstream, nicely with CRLF endings, except that when it gets built and packaged, it seems to change magically to CR endings (unix line endings).

the problem is that this particular test expects it to be in \r\n endings and thus fail in interesting ways...

is there something like an automagic CRLF convertor in our buildsystem?

does anyone know anyone who would know? can they be CC'd?

Sounds like the unix2dos command (in the dos2unix package) is what you want.

no, the tarball contains it in dos format. but the installed file is in unix format, while the tests are counting it to be in dos format.

afaics it should be in dos format, i have no idea why/how it was converted... somewhere along the way...

I'm not clear, are you wanting to fix the test or push the current build?

i do want to fix all tests eventually, but imho even the 2.7 should've been pushed. that one contains the critical security fixes. the 2.8 sort of fixes a  part of an earlier fix that slipped through the cracks, but afaik the remaining failed tests are not critical and will take a while to completely fix.

since 2.7 was validated, please validate asap 2.8 by following procedure by testing 'rpl.rpl_mdev382'

# cd /usr/share/mysql/mysql-test && ./mysql-test-run.pl rpl.rpl_mdev382

(In reply to comment #27)
> no, the tarball contains it in dos format. but the installed file is in unix
> format, while the tests are counting it to be in dos format.
> 
> afaics it should be in dos format, i have no idea why/how it was converted...
> somewhere along the way...

It's because we run: /usr/share/spec-helper/fix_eol on every rpm during build,
(and yes, we have been doing it for ages, so it's not a new thing...)

If you need to exclude some files from the stripping, you need to export the EXCLUDE_FROM_EOL_CONVERSION for those specific files in the spec.


(In reply to comment #29)
> i do want to fix all tests eventually, but imho even the 2.7 should've been
> pushed. that one contains the critical security fixes.

Well, it would have been pushed as it was validated, but you pushed 2.8 on top of it before, so you created this re-validation need....

Pressurising us is uncalled for, we were waiting for you. 

The previous package would have already been pushed if the rebuild to fix tests hadn't taken place between validation & push.


Re-Testing completed mga2 32 & 64

Re-Validating

Could sysadmin please push from core/updates_testing to core/updates

Thanks!

Updated Advisory: 
==================================
This release includes fixes for the following security vulnerabilities:

* A buffer overflow that can cause a server crash or arbitrary code execution
(a variant of CVE-2012-5611)
* CVE-2012-5627/MDEV-3915 fast password brute-forcing using the "change user"
command
* CVE-2012-5615/MDEV-3909 information leakage about existing user accounts
via the protocol handshake
* in addition it fixes MDEV-4029 and rpl.rpl_mdev382 test from mariadb-bench

References:
https://mariadb.atlassian.net/browse/MDEV-4029
https://mariadb.atlassian.net/browse/MDEV-3915
https://mariadb.atlassian.net/browse/MDEV-3909

Be advised that for CVE-2012-5615 to be completely closed, it's recommended
to remove any anonymous logins. Previously, such a user without access
rights was added by default.

https://bugs.mageia.org/show_bug.cgi?id=8921
===================================

SRPM: mariadb-5.5.25-2.8.mga2.src.rpm

Update pushed:
https://wiki.mageia.org/en/Support/Advisories/MGASA-2013-0046

Status: NEW => RESOLVED
Resolution: (none) => FIXED

(In reply to comment #30)
> (In reply to comment #27)
> > no, the tarball contains it in dos format. but the installed file is in unix
> > format, while the tests are counting it to be in dos format.
> > 
> > afaics it should be in dos format, i have no idea why/how it was converted...
> > somewhere along the way...
> 
> It's because we run: /usr/share/spec-helper/fix_eol on every rpm during build,
> (and yes, we have been doing it for ages, so it's not a new thing...)
> 
> If you need to exclude some files from the stripping, you need to export the
> EXCLUDE_FROM_EOL_CONVERSION for those specific files in the spec.

do you mean something like:

export EXCLUDE_FROM_EOL_CONVERSION=%{datadir}/mysql/mysql-test/std_data/loaddata7.dat

somewhere in the %install section?

> (In reply to comment #29)
> > i do want to fix all tests eventually, but imho even the 2.7 should've been
> > pushed. that one contains the critical security fixes.
> 
> Well, it would have been pushed as it was validated, but you pushed 2.8 on top
> of it before, so you created this re-validation need....

ah, so you can't move older builds?

(In reply to comment #31)
> Pressurising us is uncalled for, we were waiting for you. 
> 
> The previous package would have already been pushed if the rebuild to fix tests
> hadn't taken place between validation & push.
[...]

Sorry, i definately didn't mean to pressure people.

i didn't think me building a new version would cancel the push, sorry...

let you off this time ;)

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

CC: (none) => eeeemail