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)

Re:*ugh*

[JM Apocalypse]

That's odd ... I got a table not found error. Hmph.
Table 'slashdot.internet_connected_mysql_servers' doesn't exist

Where can I go to get this version of MySQL?

Re:*ugh*

[rylin]

It would seem as if your databas crashed with irreparable table corruption.
I'm afraid your server couldn't take a slashdotting ;)

damn...

[shaitand]

Thats a pretty serious vulnerability... patching now.

Re:damn...

[Anonymous Coward]

Too late, you're already 0wned!!1!

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.

Re:Not too bad though

[Anonymous Coward]

Thou kiddest! Surely everyone uses username="root" and password="" when accessing their SQL databases. After all, that's the way the textbooks show how to do it .....

Re:Not too bad though

[Anonymous Coward]

And most people who can admin the MySQL server can probably admin the whole box.

Um... No. Why would that be the case? DBA user for DBA'ing. ROOT user for ROOT'ing. And never the twain shall meet.

Re:Not too bad though

[Prowl]

My thoughts exactly. If you setup is such that this exploit is allowed, then it's likely there's plenty of other ways to root mysql.

Good to know it's fixed. And promptly too.

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.

Re:Not too bad really

[Gogo Dodo]

3.23.58 was just released.

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]

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.

Re:How is still possible?

[You're All Wrong]

The problem:
else if (length % 8)
has been 'fixed' by changing it to
else if (length % 8 || length > 16)

Basically, what that says is that the valid lengths are 0, 8 and 16, and nothing else.

Why didn't they code it using the logic:
else if (length!=0 && length!=8 && length!=16)
in the first place if that's what they meant? Except that that contains mgic numbers which should be replaced. The whole "%8" nonsense is unnecessarily indirect. Why couldn't this check be pulled out as a helper function that any compiler since 1993 would happily inline for no loss of efficiency?

It was never formally code-reviewed, I'm sure (and if it was it was code-reviewed as sloppily as it was coded), and they're reaping their reward for that as we speak.

Don't hack a bodge on a cludge. Just get it right.

YAW.

Phil

Re:How is still possible?

[Winterblink]

This is an extremely smart, well put together comment the likes of which are rarely seen on Slashdot. Now why can't you pull that one out the next time someone bitches up a storm about an overflow issue in a Microsoft product? I don't mean to play MS zealot here or anything, just asking the question.

Re:How is still possible?

[andreas]

The short answer is: because people still write software in C.

It is not a problem of laziness with programmers. People make mistakes, that's the nature of things. If you force people to take care of bounds checking themselves, they eventually will fail to miss a case. This has been proven over and over and over and over again, since buffer overflows became known as a security problem with the first Internet worm to appear.

The only thing you can do against buffer overflows is choosing an implementation language that doesn't allow buffer overflows to happen.

Re:How is still possible?

[thebatlab]

Awesome post. You forget to mention one thing but I suppose it's slightly related to Defense in Depth as you described it. Using Design by Contract, rather than the function itself validating it's own input, the client code calling that function should have validated it before it called that function.

If that function had documented itself such that client functions know it will return correct results as long as you pass it proper data (multiple of 8, = 16), then it's completely up to the client code to ensure that data is valid before calling the function. If anything goes wrong due to invalid data, the client code is at fault and should be fixed rather than the function itself being modified (as was the case in this fix).

Not to say they were wrong for doing the fix this way. It's probably the quickest and most effective way to get the fix out quickly without having to pour through multiple source code files to ensure all calls to that function (though I can't see there would be very many) and this particular check will not have a great performance penalty.

Re:How is still possible?

[sql*kitten]

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.

Great post. Mind if I quote you next time MS announces that it's found and patched another DCOM hole?

Re:How is still possible?

[cookd]

I dunno.

For one thing, I think it is reasonable to be upset about the vulnerabilities, and to hold Microsoft at least somewhat accountable -- even if it is almost impossible to catch all vulnerabilities, it still causes problems to people. It is hard to determine whether or not Microsoft has "more than their share" of vulnerabilities, since any comparison I can think of is like apples to oranges. But they do have more than anybody would like them to have (except hackers and people who want to see them fall).

For another thing, I'm not sure that anyone would listen or care. This is Slashdot, remember? People tend to accept the evidence that reinforces their current opinions, and reject the evidence that is contrary. So I don't have a lot of faith that any posting of this kind would really make any difference. Those who are determined to find fault in others (i.e. find fault in Microsoft) are probably going to find a way to blame them for all of the troubles in the world, and I can't say anything to stop them. Those who take a more reasonable approach are probably going to stay reasonable. Of course, this doesn't mean that we shouldn't post our views, but it makes me less inclined to try to do it every single time the issue arises. That would get boring really quickly (like the BSD is Dead post).

Disclaimer: I actually work for Microsoft, but they have nothing to do with my posts. Read my journal if you want to know more about where I stand. I like a lot of open source stuff, and I like a lot of Microsoft stuff. I have both a FreeBSD box and a Windows XP box running at home, and I break out the Knoppix CD every once in a while just for kicks. I really wish software were perfect, but it isn't, and the best we can do is get things fixed instead of pointing fingers (although sometimes pointing fingers is a good thing when it motivates the pointee to do a better job next time). I also use a lot of parenthesis, and I'm trying to break that habit.

Re:How is still possible?

[cookd]

Sure, go ahead, if you think it'll do any good.

Re:How is still possible?

[Cunk]

Maybe because Microsoft doesn't publish the offending code so it's impossible to critique it in any way.

Re:How is still possible?

[Tablizer]

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.

I would like to see a specific example of OOP doing such. Most examples I have seen of such simply trade one grouping aspect for another. They bring one aspect together, but force another apart, similar to the way you can't sort a sales report by region and product category at the same time (in the outer sort/grouping).

Disclaimer: I deal mostly with custom business applications, not systems software. OOP may work better there perhaps, but it is a failure for business modeling IMO.

Re:How is still possible?

[jonadab]

> Buffer overflows have been known for decades, why are these
> buffer overflows still so prevalent?

In a large program like MySQL, religiously checking each and every
buffer, each and every time anything is stored in it, without missing
any, is *hard*, because there are *lots* of buffers and they get
things stored in them by *lots* of different parts of the code.

The real solution is to use a langauge with builtin memory management.
Until recently this was impractical for performance reasons, but with
VHLL technology improving and hardware improving, it won't be too long
now before it's practical to write almost everything (save the boot
loader and scheduler and a few other lowlevel tidbits) in VHLLs. It
will then take more than twenty years to cycle out all the existing
legacy software and replace it with newer stuff, but hey.

Re:How is still possible?

[cookd]

I didn't say they succeeded, only that they try...

Yes, everything is a tradeoff. That is why it takes experience to become a good programmer, so you have a feeling of which method is most appropriate.

From my experience, OOP is most important in application and systems development. OOP means that you can provide very specific and enforceable rules about how data can be manipulated and used, and a very limited set of code that can be blamed if any of the rules are broken. The private data of a class is only accessible by members of the class, so if the private data gets into an invalid state, you know that one of the class members has to be at fault (barring spurious pointers or hardware errors). Hopefully, all of the details you need to know about when working with the class are all right there within the class, so you can see them all at once. You don't have to make as many assumptions if all of the necessary details are all together, and class organization is a good way to create independent units of functionality.

If this kind of thing isn't important (it often isn't for simpler programs), then it is just a waste of time. But for complex systems, it is always crucial. Even systems that aren't really "object oriented" from a language perspective tend to be "object oriented" from a usage perspective. Windows does it with handles. UNIX also uses handles for files and sockets. Within the Linux kernel, there are a bunch of pointers that are only supposed to be accessed via macros or accessor functions -- that is nothing short of manually-enforced object oriented programming.

Re:How is still possible?

[Tablizer]

From my experience, OOP is most important in application and systems development. OOP means that you can provide very specific and enforceable rules about how data can be manipulated and used, and a very limited set of code that can be blamed if any of the rules are broken. The private data of a class is only accessible by members of the class, so if the private data gets into an invalid state, you know that one of the class members has to be at fault (barring spurious pointers or hardware errors). Hopefully, all of the details you need to know about when working with the class are all right there within the class....

This is fairly similar to my database-centric approach to app design. Most of the larger-scale communication between tasks is through the database. The database becomes like a giant "interface board". You don't usually have to worry about where the data came from or what is going to be done with it by other tasks, you mostly just worry about what a given task needs to do with the data. It also makes debugging and logging easier because most activity passes through the database.

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.)

Re:Problem is in C libraries

[arthurs_sidekick]

The offending code is posted in the article; it makes no use of C libraries: void get_salt_from_password(ulong *res,const char *password) { res[0]=res[1]=0; if (password) { while (*password) { ulong val=0; uint i; for (i=0 ; i Looks like pretty much of a "d'oh!" coding error.

Re:Problem is in C libraries

[arthurs_sidekick]

and that was a "d'oh" posting problem (did you forget to preview?) void get_salt_from_password(ulong *res,const char *password) { res[0]=res[1]=0; if (password) { while (*password) { ulong val=0; uint i; for (i=0 ; i < 8 ; i++) val=(val << 4)+char_val(*password++); *res++=val; } } return; } Sorry folks!

Re:Problem is in C libraries

[Anonymous Coward]

Real brilliant.

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.

Re:Not that bad in the wild

[Piquan]

Regarding point a: My impression was that it does not need to be a priviledged user; by exploiting as user mysql, you still get all the access that mysql has, and may be able to use this to chain into a privilege elevation attack.

Regarding point b: If RedHat does not, by default, have any "admin" account, how are new users added?

Regarding point c: It is not unheard of, or even uncommon, for there to be flaws in web pages allowing SQL access (sometimes within certain limits).

While it's not the end of the world, and good layered security should keep this from being a problem in most installs, it's a little more serious, I think, than you imply. But just a little.

the proof of concept

[ubiquitin]

> USE mysql;
> ALTER TABLE User CHANGE COLUMN Password Password LONGTEXT;
> UPDATE User SET Password =
'3.14159265358979323846264338327950288419716939 937 51058209123456781234567812345678123456781234567812 34567812345678123456781234567812345678123456781234 56781234567812345678123456781234567812345678123456 7812345678123456781234567812345678...' WHERE User = 'abcd';
> FLUSH PRIVILEGES;

[Connection lost]

Re:the proof of concept

[pooh666]

Hi,

You know this is just amazing to me that this is even considered a bad issue. That it was even posted on Slashdot I mean, if you are already admin chances are you have shutdown priv so what is the difference?? Seems to me mysql caught this way early and so that it will never cause a real problem.

Eric

Password problems?

[Silverblade]

This problem is going to make it easier for hackers to get into programs all together now. For all those people who are, you have a major oppurtunity here. But for those who aren't you can't even have a password that is 128 bit encryption anymore. That isn't even good enough. Maybe a 512 bit would help but knowing the "Hacker" age now?! Good luck protecting your computer now

Re:Password problems?

[Anonymous Coward]

-1, Ignorant

Please read and understand the article before spewing trollshit like this.