Without going into unnecessary details about CVE-2012-5612 bug; an authenticated database user could use this flaw to crash MySQL instance or even try executing some code. Is it a serious problem? Do you need to worry about it?
I recently saw some comments that "My database is safe, only application can access it. Is it really a serious bug?" which scared me a bit. Such opinion might be fine but only for closed systems with limited access to MySQL, but what if you are hosting provider that share single MySQL instance between several accounts? Here, security matters a lot! Especially if you allow users to create test/demo accounts.
Based on comments from security lists, only 5.5 family of MySQL is affected since the vulnerable MDL subsystem was first implemented in mysql-5.5. That's why I decided to do some testing against most popular 5.5 distributions on market.
My tests covered:
- vanilla MySQL5.5.28
- Percona Server 5.5.28
- MariaDB5.5.28
MySQL 5.5.28
I started from MySQL5.5 (vanilla one, remi repository for CentOS-6):
Exploit execution:
[root@terror ~]# perl ./mysql_heapoverrun_pl.bin
AAAA..AASE dUAAAA..AAE dUSAAAA..AA dUSEAAAA..AAdUSE AAAA..AAAAAA..AAHOW TABLES FROM dSAAAA..AAOW TABLES FROM dSHAAAA..AAW TABLES FROM dSHOAAAA..AA TABLES FROM dSHOWAAAA..AATABLES FROM dSHOW AAAA..AAABLES FROM dSHOW TAAAA..AABLES FROM dSHOW TAAAAA..AALES FROM dSHOW TABAAAA..AAES FROM dSHOW TABLAAAA..AAS FROM dSHOW TABLEAAAA..AA FROM dSHOW TABLESAAAA..AAFROM dSHOW TABLES AAAA..AAROM dSHOW TABLES FAAAA..AAOM dSHOW TABLES...
MySQL died. Quick checkout in logs explained why:
*** glibc detected *** /usr/libexec/mysqld: munmap_chunk(): invalid pointer: 0x00007fd720013490 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x75916)[0x7fd74277b916]
/usr/libexec/mysqld(free_root+0xe9)[0x77a4c9]
/usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x2cc)[0x5847cc]
/usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0xd2)[0x614772]
/usr/libexec/mysqld(handle_one_connection+0x50)[0x614880]
/lib64/libpthread.so.0(+0x7851)[0x7fd74428f851]
/lib64/libc.so.6(clone+0x6d)[0x7fd7427ee11d]
MySQL5.5.28 is vulnerable.
Percona Server 5.5.28
Later on, I took latest available Percona Server, 5.5.28-29.1-log Percona Server (GPL), Release rel29.1, Revision 335:
11:55:39 UTC - mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
Please help us make Percona Server better by reporting any
bugs at http://bugs.percona.com/
Percona Server 5.5.28-29.1 is vulnerable.
MariaDB 5.5.28a
And finally MariaDB. Latest available 5.5.28a-MariaDB-log.
121204 13:30:03 [ERROR] mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
To report this bug, see http://kb.askmonty.org/en/reporting-bugs
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
5.5.28a-MariaDB-log is vulnerable too.
As you can see, all latest versions/forks of MySQL5.5 are vulnerable. Does it mean that you should downgrade to 5.1? No! Please keep in mind that for CVE-2012-5612 bug MySQL is exploitable only if attacker has gained access to database. What you should do instead of downgrade is:
- review users of your database and corresponding grants
- limit access to MySQL database (eg. user@host)
- block access to your MySQL from the internet
- perform periodic security audits of MySQL
- review security alerts on our Blog ;)
- use external security mechanisms (e.g.. selinux)