hacker1_wideweb__470x305,0

Critical Security Vulnerability In MySQL/MariaDB Sql Database

Recently on 9th June, Sergie Golubchik (MariaDB Security Coordinator) posted to the oss-sec mailing list about a secrutiy flaw in the MySQL and MariaDB database servers. All MariaDB and MySQL versions up to 5.1.61, 5.2.11, 5.3.5, 5.5.22 are Vulnerable to it.

Sergei writes “We have recently found a serious security bug in MariaDB and MySQL. So, here, we’d like to let you know about what the issue and its impact is. At the end you can find a patch, in case you need to patch an older unsupported MySQL version.”

He explains the vulnerability as 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, it might’ve happened that the token and the expected value were considered equal, even if the memcmp() returned a non-zero value. In this case MySQL/MariaDB would think that the password is correct, even while it is not.  Because the protocol uses random strings, 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.

In short, if you try to authenticate to a MySQL server affected by this flaw, there is a chance it will accept your password even if the wrong one was supplied. The following one-liner in bash will provide access to an affected MySQL server as the root user account, without actually knowing the password.

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

mysql>

Whether a particular build of MySQL or MariaDB is vulnerable, depends on how and where it was built. A prerequisite is a memcmp() that can return an arbitrary integer (outside of -128..127 range). To my knowledge gcc builtin memcmp is safe, BSD libc memcmp is safe. Linux glibc sse-optimized memcmp is not safe, but gcc usually uses the inlined builtin version.

Who is Vulnerable to It?

According to stats by HD Moore, Approximately 1.74 million MySQL servers across the internet are vulnerable to it. The 5.0.x version series accounts for over 356,000 of the entire set, followed by 285,000 running a 5.1.x version, and 134,436 running a 5.5.x version.

This statistic only includes MySQL Servers that were on hosts publicly exposed to the internet. There are countless numbers of MySQL servers on Localhosts.

How to secure it?

If you are have a MySQL server that is currently exposed to the network unnecessarily, the easiest thing to do is to modify the my.cnf file in order to restrict access to the local system. Open my.cnf with the editor of your choice, find the section labeled [mysqld] and change (or add a new line to set) the “bind-address” parameter to “127.0.0.1″. Restart the MySQL service to apply this setting.

You can also update your current database version. Though, this is a very critical vulnerability, still not many people know about it. We hope the server administrators reading this article will fix their web servers and of course their localhosts, before someone breaks into the house. ;)

 

Source: Originally Published in Hacker5 Magazine July Issue

Author: Naveen Singh

Share The Post :)
1 reply

Trackbacks & Pingbacks

  1. [...] Platforms, but still hackers are able to exploit the vulnerabilities in WordPress. Below are some vulnerability in WordPress and we will teach you how to tackle with them in order to secure WordPress website [...]

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>