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