Bug 5881 - mysql new security issue fixed in 5.5.24 (CVE-2012-2122)
Summary: mysql new security issue fixed in 5.5.24 (CVE-2012-2122)
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 1
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact:
URL:
Whiteboard: mga1-32-OK mga1-64-OK
Keywords: validated_update
Depends on:
Blocks:
 
Reported: 2012-05-13 03:15 CEST by David Walser
Modified: 2012-06-19 17:45 CEST (History)
5 users (show)

See Also:
Source RPM: mysql-5.5.23-1.mga1.src.rpm
CVE:
Status comment:


Attachments

Description David Walser 2012-05-13 03:15:49 CEST
Oracle has released MySQL 5.5.24 and says a security bug was fixed:
http://dev.mysql.com/doc/refman/5.5/en/news-5-5-24.html

Considering there's no information available on it and where we are in the Mageia 2 release process (where we have MariaDB 5.5.23), we should probably wait until after Mageia 2 to handle this.  Also, we'll have a little bit more information once the next Oracle Critical Patch Update is posted here:
http://www.oracle.com/technetwork/topics/security/alerts-086861.html
David Walser 2012-05-13 03:16:38 CEST

CC: (none) => alien

David Walser 2012-05-13 03:16:47 CEST

CC: (none) => tmb

Comment 1 AL13N 2012-05-13 22:20:30 CEST
MariaDB people have found a problem, fixed it, and sent it to Oracle (among others).

(For the record, I find it appalling that Oracle completely disregards where patches come from, and try to obscure it, which even is problematic even identifying which fix is which...)

The patch below will likely work for mysql as well.

Since Oracle released the fix, i see no problem revealing this info:
---------------

Here's the issue. When a user connects to MariaDB/MySQL, a token (SHA over a
password and a random scramble string) is calculated and compared with
the expected value. Because of incorrect casting, only the first byte
of the comparison was used, so if this token and the expected value
started from the same byte - the password was considered correct.
Because a random string is involved, the probability of hitting this bug
is about 1/256.

Which means, if one knows a user name to connect (and "root" almost
always exists), she can connect using any password by repeating
connection attempts. ~300 attempts takes only a fraction of second, so
basically account password protection is as good as nonexistent. 
Any client will do, there's no need for a special libmysqlclient library.

Of course, all users are recommended to upgrade ASAP.

Here's the patch against MariaDB 5.1:

=== modified file 'sql/password.c'
--- sql/password.c      2011-11-21 17:13:14 +0000
+++ sql/password.c      2012-04-04 13:41:50 +0000
@@ -503,7 +503,7 @@ check_scramble(const char *scramble_arg,
  mysql_sha1_reset(&sha1_context);
  mysql_sha1_input(&sha1_context, buf, SHA1_HASH_SIZE);
  mysql_sha1_result(&sha1_context, hash_stage2_reassured);
-  return memcmp(hash_stage2, hash_stage2_reassured, SHA1_HASH_SIZE);
+  return test(memcmp(hash_stage2, hash_stage2_reassured, SHA1_HASH_SIZE));
}
Comment 2 AL13N 2012-05-14 12:54:58 CEST
ok, so i'll add for clarity that to preserve upgradability, mysql should be patched with this, NOT updated to new version.

also, after you're done with this, plz make sure mariadb in mageia 2 is a higher version-release.
Comment 3 Sander Lepik 2012-05-14 13:02:53 CEST
Why should mariadb be higher version? It's another name? Isn't it?

CC: (none) => sander.lepik

Comment 4 David Walser 2012-05-14 13:10:44 CEST
mariadb Provides/Obsoletes mysql <= %{version}-%{release}, so that's why.  Granted it could obsolete a higher version, but that'd be awkward.
Comment 5 AL13N 2012-05-14 20:36:57 CEST
I think since it also provides mysql, it can't be less... unless we use epoch, but i'd rather not, since normally updates don't get newer versions, just the update patches. since i have normally maybe access to the same patches in mariadb, i'll try and keep this sort patches going so that we won't have these kinds of troubles in the future.
Comment 6 David Walser 2012-06-11 14:33:44 CEST
This is now public:
http://www.h-online.com/open/news/item/Simple-authentication-bypass-for-MySQL-root-revealed-1614990.html

It has been assigned CVE-2012-2122, and the details are exactly as Maarten explained.  We can issue a fix now.

Summary: mysql new security issue fixed in 5.5.24 => mysql new security issue fixed in 5.5.24 (CVE-2012-2122)

Comment 7 Thomas Backlund 2012-06-12 10:50:55 CEST
There is now a mysql-5.5.23-1.1.mga1 to validate that has the fix applied:

- fix Simple authentication bypass for MySQL root (CVE-2012-2122)


And yes, the subrel is intentional in order to keep upgrade path to mga2 even if we have to release more updates...


Testing exploit:

$ for i in `seq 1 1000`; do mysql -u root --password=bad -h 127.0.0.1 2>/dev/null; done

Result before: gain mysql root access
(end up at "mysql>" prompt)

Result with fixed rpm: no mysql root access

Status: NEW => ASSIGNED
Assignee: bugsquad => qa-bugs

Comment 8 Dave Hodgins 2012-06-12 22:09:53 CEST
Testing complete on Mageia 1 i586 for the srpm
mysql-5.5.23-1.1.mga1.src.rpm

It seems i586 is not susceptible to the bug, so just testing
that mysql works, using phpmyadmin to create a table, etc.

CC: (none) => davidwhodgins
Whiteboard: (none) => mga1-32-OK

Comment 9 claire robinson 2012-06-12 23:54:12 CEST
Testing complete Mageia 1 x86_64, also not susceptible.

Checked with pypmyadmin.

Validating


Advisory
--------------
This update provides a fix for the Simple authentication bypass for MySQL root (CVE-2012-2122).

Mageia 1 does not appear vulnerable to this CVE but has been patched anyway.
--------------

srpm: mysql-5.5.23-1.1.mga1.src.rpm

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

Thanks!

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs
Hardware: i586 => All
Whiteboard: mga1-32-OK => mga1-32-OK mga1-64-OK

Comment 10 Thomas Backlund 2012-06-19 17:45:03 CEST
Update pushed.
https://wiki.mageia.org/en/Support/Advisories/MGASA-2012-0115

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


Note You need to log in before you can comment on or make changes to this bug.