Bugtraq mailing list archives
Re: mSQL vulnerabilities
From: davids () silence secnet com (David Sacerdote)
Date: Tue, 29 Jul 1997 15:37:05 -0600
All mysql string are (own coded) C++ strings and the String class includes a length so this problem doesn't exists.
No. At least a few are on the stack. Look at mysql_rm_table() in 3.20.24a for example: int mysql_rm_table(THD *thd,tname_t *tables) { char path[FN_REFLEN]; ... (void) sprintf(path,"%s/%s/%s%s",mysql_data_home,thd->db,table->real_name, reg_ext); I've not traced the functions which call mysql_rm_table to see if they do bounds checking, but what I see it doing is the kind of thing which makes me feel nervous, and suspect a hole, as my initial post to the bugtraq mailing list indicated. I have not *confirmed* or *exploited* any holes in MySQL as of this afternoon.
APIS> A second vulnerability exists due to the fact that the mSQL server does APIS> not perform a forward DNS lookup on the results of reverse DNS lookups, APIS> allowing users able to spoof hostnames to access the mSQL server. MySQL doesn't do this either, the main reason is that DNS lookup is so slow. If one wants harder security one shouldn't use host names for users without passwords. Hosts in /etc/host is ok and one can always use IP's.
If one wants speed, one should use IPs. Doing DNS right is not the place to comprimise. This stuff is done *once* per tcp connection. And no, placing hosts in /etc/hosts doesn't solve the problem. Given that frequent users will wind up in your resolver cache somewhere fairly local, I see no reason not to make use of both a reverse lookup and a forward lookup in situations where hostname based access control is used. It'll be slow the first time, and fairly fast after that.
APIS> In addition to the above buffer overflows, the username/hostname APIS> based access control mechanism in the msql daemon does not protect APIS> against an attacker with control of a DNS server: APIS> hp = (struct hostent *)gethostbyaddr( APIS> (char *)&conArray[newSock].remote.sin_addr, APIS> sizeof(conArray[newSock].remote.sin_addr), APIS> AF_INET); If you are real strict, a user with cntrol of a DNS server may also in some cases simulate another IP and even answer IP checks.
Not on a TCP session when you've got non-guessable TCP sequence numbers, unless they're on the return path for your packets anyways, or can do source routing. In either of those two cases, you're screwed anyways. Don't use a fixed hole as an excuse for not doing things right.
APIS> Remote individuals can induce the msqld or msql2d to execute arbitrary APIS> commands. If the msqld or msql2d is run as 'root', then an attacker APIS> can obtain root priviliges. I can't see how one can get root privileges with MySQL or even mSQL; One can't create/modify files or execute arbitrary shell commands. In mSQL on can only execute arbitrary SQL commands but I can't se how this would help.
If the SQL server software is running as root, and there is a stack buffer overflow in the SQL server software, where an attacker can cause the server software to write arbitrary data onto its stack, then the attacker can induce it to execute arbitrary machine code. I think this is fairly clear to any regular bugtraq reader. If you would like a detailed explanation of how a stack buffer overflow can be used by an attacker to execute arbitrary commands, see the bugtraq post "smashing the stack for fun and profit" by the bugtraq moderator. A copy can be found at http://www.geek-girl.com/bugtraq/1996_4/0196.html
In 3.21.2 I have also fixed dynamic string handling of 'database name' and 'table_name', which was the only static non checked buffers I know about. Please inform me if you can find any other buffers that may overflow :)
I am planning to take a very close look at the 3.20.24a release, or any more recent release you choose to provide me some time in the next week. Please do not force me to post detailed descriptions of verified holes in MySQL to public mailing lists before we can discuss fixes. David Sacerdote
Current thread:
- mSQL vulnerabilities Secure Networks Inc. (Jul 27)
- Re: mSQL vulnerabilities Stacey Son (Jul 28)
- <Possible follow-ups>
- Re: mSQL vulnerabilities David Sacerdote (Jul 28)
- Re: mSQL vulnerabilities David Sacerdote (Jul 29)
- Re: mSQL vulnerabilities Black Adder (Jul 29)