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

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?

[_iris]

The biggest reason I miss these is the development process itself. Before you ever write the code, you define the behevior of each subsystem, the inputs, outputs, and so forth. You become so locked into this specific set of conditions that you pay far less attention to other possible uses.

This issue can be seen in this exploit. The programmers knew the structure of the mysql database tables. Because of this they assumed the input to the function would always come from the mysql tables and wrote the code accordingly. [note: this is obviously speculation]

Problem is in C libraries

[Anonymous Coward]

Clearly, the problem here is in C's libraries itself. I can think of no program that smashes the stack for a legitimate reason, so why aren't functions such as strcpy and gets rewritten to do bounds checking? It would save us admins from a lot of troubles!

Re:Problem is in C libraries

[JAgostoni]

I'll bet if C compilers started doing this then a bunch of people would start complaining that C is becoming too "VB" like. It would be nice to see all C compilers at least having an "optional" bounds-checking setting that would insert code to check bounds for you (ala VB). But that would lead to even lazier coding. (Have you seen the sample Linux/SCO/Unix code floating about, that's some pretty ugly code if you ask me.)

Not that bad in the wild

[image]

In practice this one doesn't sound bad as the following conditions need to hold true:

a) the MySQL instance needs to be installed as root or other priviledged user
b) the attacker needs to have an admin account
c) the attacker needs direct access to MySQL (either via a shell account on that box or over the MySQL port)

Fortunately:

a) the default install of MySQL via RPM on RedHat is as "mysql:mysql"
b) there is no default "admin" account
c) MySQL boxes are very rarely directly exposed to the internet, and the default install does not allow remote connections at all

So even though there is a pretty bad buffer overflow, the multi-layered security approach of MySQL fends off the likelihood of widespread exploitation. Note how different this is than the SQL Server vulnerabilities that have plauged the internet for the past few years.

And it speaks to the strength of OSS that the bug was found and patched at all. And to MySQL AD for applying the patch ASAP. In the closed source world, the same type of people that find exploits like this tend to not be as respectful of the software manufacturers or their customers.