Kaj is responsible for communicating and evangelizing MySQL within the software development community -- as well as representing the community's interests to MySQL's senior management team. He has been with MySQL since 2001 in a variety of executive positions, including managing the company's relationship with SAP. Prior to MySQL, he founded and was CEO of Polycon Ab, a training and professional services provider in Finland and Germany. He began his professional programming career with Datema and IBM.
The phrase "security vulnerability" gives most of us the creeps. We are afraid of them. Looking at them rationally, they share a trait with other bugs: All are a pain, but some are a bigger pain than others. And instead of trying to avoid the evil by not talking about it, let's take a look at MySQL's security vulnerability track record over the years, and explain the rationale behind our actions using actual cases from past years.
Let me start by pointing out that the MySQL database -- like all large software products -- has had, and in all likelihood still has, security vulnerabilities. As an often used default database for web apps, MySQL is pounded upon from a number of different directions. Since one of the most important user criteria is that the database must be secure, let me also be clear that MySQL treats security vulnerabilities as the highest-priority of all bugs and promptly allocates resources towards fixing such bugs when they are reported, as described below.
Yet, every single alleged security vulnerability does not merit MySQL's release of new binaries, nor do all of them require you as a user to upgrade your version of the database.
So in order to better be able to assess any future threat situation, let us take a deep breath and explore what "security vulnerabilities" are, how they are classified, how they are discovered, how MySQL gets to know about them, what the MySQL Security Team is and what the roles of the team members are, how the vulnerabilities are fixed, how the fixes are distributed and communicated, and whether you should care.
Looking up "security vulnerability" in Wikipedia provides the following definition (http://en.wikipedia.org/wiki/Security_vulnerability):
"In computer security, the word vulnerability refers to a weakness in a system allowing an attacker to violate the confidentiality, integrity, availability, access control, consistency or audit mechanisms of the system or the data and applications it hosts. Vulnerabilities may result from bugs or design flaws in the system. A vulnerability can exist either only in theory, or could have a known exploit. Vulnerabilities are of significant interest when the program containing the vulnerability operates with special privileges, performs authentication or provides easy access to user data or facilities (such as a network server or RDBMS)."
The Wikipedia article points out the possible causes of vulnerabilities:
"Vulnerabilities often result from the carelessness of a programmer, though they may have other causes. A vulnerability may allow an attacker to misuse an application through (for example) bypassing access control checks or executing commands on the system hosting the application. Some vulnerabilities arise from un-sanitized user input, often allowing the direct execution of commands or SQL statements (known as SQL injection). Others arise from the programmer's failure to check the size of data buffers, which can then be overflowed, causing corruption of the stack or heap areas of memory (including causing the computer to execute code provided by the attacker)."
The MySQL Security Team is not a dedicated, separate team but a cross-functional group of employees who in case of a verified security vulnerability are prepared to promptly focus on the issue until the problem is fixed and applied to the source code. Depending on the nature of the security issue, a build is made, and the issue isn't closed until affected customers have been alerted and the vulnerability, and the subsequent 'fix' has been communicated to the user base. For more on how MySQL prioritizes security vulnerabilities and our response guidelines, see the section entitled “Rationale: Not all security vulnerabilities are created equal” below.
The security team can be contacted via email@example.com. The security team is comprised of:
The security team convenes not only when a severe security vulnerability is reported, but also regularly resolves less urgent security vulnerabilities.
If you discover what you think is a security vulnerability, please send a bug report to firstname.lastname@example.org. You are then the "original reporter" of the vulnerability. We will attempt -- but not promise -- to keep you in the loop by send you a patch whereby you can verify if our fix does address the issue.
Please don't report security vulnerabilities as a bug through bugs.mysql.com. The rationale behind this is to decrease the likelihood of exploitation of the security vulnerability during the time we are fixing the vulnerability as bugs.mysql.com can be viewed publicly. Our best security vulnerability reporters (those that write the largest number reports, as well as those who make the most complete, comprehensive and easy-to-reproduce vulnerability reports) have been very cooperative in reporting to email@example.com, and not issued publicly accessible reports until we've been given a fair chance to fix the issue.
Those are the steps external to MySQL. What happens once MySQL receives a vulnerability report?
First, if the security vulnerability is sent in through bugs.mysql.com, we may mark the bug private, in effect making it invisible outside the members of the Security Team plus a few other developers at MySQL AB.
Second, we allocate resources based on the anticipated effects of the security vulnerability. (For our rationale when assessing the bug, read on.)
Third, we verify the bug, using our normal bug verification processes (which may involve the Security Team members) but with a priority that surpasses all non-security issues.
Fourth, if an alleged security vulnerability is verified, our bug fixing resources are immediately reprioritised to fix the security bug before all other ongoing work. In severe cases, this may mean calling people out of their beds.
Fifth, the fix is reviewed by other developers and documented by a Documentation Team member, adding a note to the Release Notes. Again, these reviews are prioritised over outstanding tasks of the needed resources, and for severe cases, the additional reviewers have already been notified in step two and are standing-by to assist.
Sixth, for vulnerabilities where non-MySQLers haven't applied for a CVE number from MITRE (for a definition, see below), we will do so. However, we haven't done so in all cases during the last nine years of MySQL, and we're improving our practices in this area.
Seventh and last, the MySQL Build Team creates the official release, publishes and announces it in cooperation with our Community team. For our commercial customers on MySQL Enterprise, a separate update alert is written and broadcast.
The rationale for our actions and priorities behind fixing security vulnerabilities is based on common sense reasoning. MySQL does not have a formal Security Policy, by which an outside authority could determine which treatment we give a particular security vulnerability. At some point, we may choose to publish an explicit Security Policy and your input regarding a Security Plan is welcome. Feel free to send your ideas to the security mailing list, to the equivalent Community Team mailing list (firstname.lastname@example.org), or to Lenz and myself at email@example.com.
The most important factor that determines the seriousness of a security vulnerability is whether its effects are limited to the realm of MySQL, or if it affects the whole operating system, outside the realm of MySQL. This may occur for certain types of bugs, such as buffer overflows, where in some situations the exploiter can execute random machine code pushed by the exploiter.
Realm of vulnerability: MySQL or arbitrary code execution
The second most important factor that determines the seriousness of a security vulnerability is whether it occurs through a remote application user, without operating system privileges, or whether the MySQL Server is vulnerable only by local attack by users carrying credentials on the Operating System level.
Required OS privileges for triggering the vulnerability
A third factor that determines the seriousness of a security vulnerability is whether it requires MySQL privileges or not.
Required MySQL privileges for triggering the vulnerability
The fourth factor, the likelihood of an exploit, is hard to quantify. At one extreme end, we have exploits which are theoretical; there are no known exploits. At the other end, we have exploits with a how-to-reconstruct published on the web. Between these far ends, there is a continuum where only experience can be used to judge the real likelihood.
Likelihood of an exploit
While "crashing the server" may look serious, because of the connotation of the word "crash", arguably it's much worse if access to real data is gained.
Nature of vulnerability: Server crash or access to data
There are further criteria, some of which may explain some of our reasoning towards the likelihood of an exploit.
Type of MySQL software which is vulnerable
Denial of Service -- or potentially corrupting data
Effect of security precautions
Maturity of version on which the bug occurs
Today, MySQL has no formal definition of an "exploitable" security vulnerability. We try to err on the side of being cautious, but on the other hand, we do want to react more swiftly to real threats than potential ones. Hence, for the purpose of this article, I've used the expression "exploitable" to mean "a known exploit exists, or is likely to exist within a short timeframe", as opposed to "theoretically possible to exploit within a finite timeframe". Both definitions are defensible, and we've picked ours with the interests of the users in mind. If you have improvement suggestions, tell us!
While MySQL does not have a formal Security Policy, in practice, we intend to give vulnerabilities roughly three levels of treatment:
Attempted time to fix: Within hours of discovery. New MySQL Enterprise Server binaries issued: Within a week (ASAP, often quicker). New MySQL Community Server binaries issued: Within two weeks (ASAP, often quicker). Triggering effects:
Attempted time to fix: Within hours of discovery. New MySQL Enterprise Server binaries issued: Within two weeks (ASAP, often quicker). New MySQL Community Server binaries issued: No. Triggering effects:
Attempted time to fix: Within days or weeks of discovery. New MySQL Enterprise Server binaries issued: No. New MySQL Community Server binaries issued: No. Triggering effects:
Quite like most societies have set up independent policing authorities and don't rely on private security companies, the concept of an independent security organisation exists in the IT industry. The most authoritative of these is probably the MITRE Corporation (http://www.mitre.org), a US-based not-for-profit organization chartered to work in the public interest.
MITRE keeps a list of CVEs or Common Vulnerabilities and Exposures. Some of these are related to MySQL. When I searched the MITRE web site with the keyword "mysql" (http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=mysql) in late June 2007, I got 137 CVE entries, with the first one from 1999. Most of these entries ended up on the list because they are related to applications that use MySQL, so the more relevant number is the number of entries related to MySQL software provided by MySQL AB itself (notably MySQL Server, but in some cases also the Client software). Applying this criterion gives us 58 entries, of which two were disputed by MySQL AB at the time they occurred.
I asked MySQL's co-founder and MySQL Fellow, Michael "Monty" Widenius to take a look at these 56 security vulnerabilities, reported over a total of 9 years, and classify them. Based on this work, Lenz Grimmer (now in our Community Relations Team, but with a past track record in the Build Team) and Giuseppe Maxia (now in our Community Relations Team, but with a past track record as an external MySQL community member and a member of the MySQL Quality Assurance Team) documented a list of all individual cases. This list is now available on MySQL Forge at http://forge.mysql.com/wiki/Security_Vulnerabilities_In_MySQL_Server, with CVE numbers, dates and times when they were fixed in MySQL. I got plenty of help from several members of the Security Team at MySQL.
To learn more from MySQL's past track record, and to ensure a good security policy in the future, we went through all 56 Security Vulnerabilities from 1999 to mid-2007 and placed them into seven categories (worst case first):
Definitions: A "remote user" is a user of MySQL, regardless of point of access, who does not have shell access to the underlying operating system that MySQL runs on. A "local user", on top of MySQL access, also has shell access.
Of these, the first six are true, undisputable vulnerabilities. The seventh one depends on the viewpoint. We may see it as "not a real problem", whereas one may also claim that this last category consists of design flaws. There are three such CVE entries from 1999 to mid-2007.
|Year||Hijack||Remote user||Local user||Minor||None||Total|
Source: Security Vulnerabilities in the MySQL Server by Lenz Grimmer, classified by Michael "Monty" Widenius
Let me provide you with all known examples of security vulnerabilities giving remote users access to MySQL Server:
Some sample security vulnerabilities through which remote users can crash MySQL Server:
Examples of security vulnerabilities not belonging to the most serious category:
Lastly, an example of a vulnerability raised because it represents surprising (to the reporter) behaviour potentially related to security. But not all of these are issues where the unexpected behaviour is unintended. Here is an example from 2006:
To conclude, let's see an example of a false alarm, presented to the MySQL Users Conference 2007. The fear started with an intimidating blog entry (Are you prepared for the attack of the MySQL worm?, followed by bug report #28089). The reporter describes an attack through a chain of compromised MySQL servers via Federated tables as highly probable. Fortunately, at the Users Conference there were all the experts on Federated tables and the report was quickly analyzed. Within hours, the alleged vulnerability was reduced to a largely improbable case, where most DBAs must drop all the default defenses and use lousy passwords in order for the attack to start. This case did not even become a CVE entry. It was defused with the full understanding of everyone involved, including the author of the initial report.
The purpose of this article is to describe how MySQL has treated security vulnerabilities. It's a documentation of the guidelines according to which we've worked. In case you are involved with security issues, do let us know how we can improve, from the perspective of the MySQL user base in general, or from your specific perspective! You can reach the relevant people under firstname.lastname@example.org, email@example.com or Lenz Grimmer and myself directly under firstname.lastname@example.org.
Read and post comments on this article in the MySQL Forums. There are currently 4 comments.