Buffer Overflow in MySQL

maedls.at writes "Here is a short description of the Vulnerability:Passwords of MySQL users are stored in the "User" table, part of the "mysql" database, specifically in the "Password" field. In MySQL 4.0.x and 3.23.x, these passwords are hashed and stored as a 16 characters long hexadecimal value, specifically in the "Password" field. Unfortunately, a function involved in password checking misses correct bounds checking. By filling a "Password" field a value wider than 16 characters, a buffer overflow will occur. For details and proof of concept see: http://lists.netsys.com/pipermail/full-disclosure/ 2003-September/009819.html"

Comments

*ugh*

[rylin]

SELECT hosts FROM internet_connected_mysql_servers WHERE patched = 1;
Empty set (0.00 sec)

Not too bad though

[Prowl]

The mysql user must have administrative privileges to exploit the bug

ie. access to the mysql table itself

Re:Not too bad though

[jpkunst]

The mysql user must have administrative privileges to exploit the bug
ie. access to the mysql table itself

If that is the case, there should be no problem unless the specific database for your application is accessed with the MySQL 'root' user (which would be very bad design) .

JP

Re:Not too bad though

[cookd]

More detail:

First, ALTER the User table of the mysql database (the table that contains the usernames and passwords of users allowed to connect to the database server) so that the Password column can have more than 16 characters.

Second, UPDATE a row in the User table to give a user a "password" consisting of your buffer overflow code.

Third, get MySQL to try to process that user's login info. This is done with "FLUSH PRIVILEDGES" which flushes the cache of users and their passwords.

You now can execute code in the context of the MySQL server.

Of course, the MySQL server should be running as an unpriviledged user anyway. And most people who can admin the MySQL server can probably admin the whole box.

Just goes to show that nobody's perfect, I guess.

Vendor Status

[dago]

MySQL AB has been informed of this vulnerability on Wed, 6 Aug 2003.

The issue was confirmed and fixed in the developpment tree the next day.

[side note: the MySQL developpment team is not only very reactive, the guys
are also extremely nice]

Not too bad really

[quinkin]

It's not as bad as I thought reading the banner - you need global administrator rights to perform the exploit. Most hosting servers will be pretty well protected - I certainly think I am.

But there is no point tempting fate, and it's a good excuse to update anyway. :)

Bugs fixed: * Fixed buffer overflow in SET PASSWORD which could potentially be exploited by MySQL users with root privileges to execute random code or to gain shell access (thanks to Jedi/Sector One for spotting and reporting this one).

All fixed. Get your 4.0.15 here.

Unfortunately, it seems that release 3.23.58 is "to be released soon". So people with older installations will have to be extra careful until an update is released.

Q.

How is still possible?

[Anonymous Coward]

In advance: You can mod me down to Flamebait, but I personally think my question is very interesting.

Buffer overflows have been known for decades, and lots of programs exist to automatically search for them. And it's not that difficult either for someone who knows nothing about programming, to enter very large values in some fields, and see if a "Segmentation Fault" occurs.

My question here is, why are these buffer overflows still so prevalent? Is it because programmers are lazy? Too lazy to scan the source code with automated scanners to find buffer overflows? Knowing that MySQL is a very crucial program, that's just begging to be exploited, why did no one (else) care to search for buffer overflows before the source code was released? Or is there a deeper problem here?

Re:How is still possible?

[cookd]

The question shows that you haven't done a lot of real world programming, or if you have, you don't understand a lot of the issues. MySQL has been very carefully searched for overflows, but some overflows are very subtle and much harder to find than you might imagine.

It isn't that programmers are lazy (which we are, but that isn't the problem). It is that programmers can't keep perfect track of everything at once, and have to make assumptions. What am I supposed to tell my boss, something like "I can't start on that bug fix until I have read and perfectly comprehend all 1,500,000 lines of code in the product"? No, I have to try to get an overall idea of how things work, and dig into the details as I think necessary. This sometimes means I will miss a detail that is indirectly connected to the work at hand, and therefore make a mistake. The most important (in my opinion) and difficult work being done in computer science is in ways to organize things so that all of the details needed for a single problem are obvious and connected. Thus comes OOP and other programming methodologies that try to keep programs organized and well-structured.

If you read the article, it showed the code at fault. It wasn't just one function, but two. One function "validated" the password. Later, another function worked with the password, assuming (correctly) that it had already been "validated". The problem was that the two functions had different ideas about what it meant to be "validated". If the error had all been within one single function, then this would be almost inexcusable. But since the problem was a coincidence of two less significant flaws, it was much harder to detect. And if some automatic overrun detection tool were to flag the code, the programmer examining the warning would very likely have determined that the tool's warning was incorrect -- "the parameter was validated already before this function call, so the buffer overrun cannot happen."

Next, you can't just enter larger values to detect everything. In this case, the database ships with a 16 char limit on the password field. So sending a large value for password wouldn't work -- the value would be truncated when it went into the database. The bug is triggered by three unrelated operations in sequence: you alter the database to allow for larger values, THEN set a large value for password, and THEN flush the table. Automatic tools can't try every possible sequence of input, just a subset.

Aside from simply "getting it right in the first place" (i.e. never making invalid assumptions, which is pretty much impossible) this kind of problem can be avoided by using one of two programming.

The first is "Defense in Depth", which means that a function isn't allowed to assume that a parameter has been validated -- every function must validate every parameter ever time it is called. This works, but it has performance penalties (a parameter can be passed around hundreds of times, so now we validate it hundreds of times instead of just once). It also is boring to program the validation code, and therefore likely to be forgotten in some crucial function. Finally, validation is hard to get exactly right, and if the concept of a valid parameter changes, you have to go change it in every place it is validated.

The second is automatic handling of the situation. Use a string class of some sort, like STL's string, or use a "safe" language like Java or C#. This is better, but again it has costs in performance, as well as ignores the problem of interoperating with existing code.

So the "deeper problem" is that we can never get everything perfect by hand, and the automatic solutions come at a price we often aren't willing to pay. Solution? None at the moment. Perhaps in the future, less code will be written in "unsafe" languages (languages with potential for overflows), so buffer overflows will only be a problem for those who write the compilers and runtimes for those safe languages. But I wouldn't hold my breath -- it will be a while. And when that day finally comes, there will still be plenty of other ways to "root" a machine -- buffer overflows aren't the only way to overcome security measures.