Benjamin Pflugmann wrote:
>
> Hi.
>
> All your arguments are irrelevant regarding my post: Sergei stated
> that MySQL 3.23 would not be vulnerable to the posted exploit and I
> proved it is (respecting the rules given in the exploit). I never
> argued about the impact of the exploit.
>
> To be true, I am worried about the answers we get. First, I wonder
> about how Sergei was not able to repeat it, when I had no problem. A
> test case showing that it did not work for him would have been nice
> (sorry, Sergei, no harm intended).
>
> Then you simply "talk away" the harm of this exploit, and ignore what
> was said before. All your arguments may be valid, but have nothing to
> do with the fact that there is an exploitable bug, regardless how many
> impact it has.
>
> In fact, until now, nobody from MySQL even officially acknowledged that
> there is a problem, except implicitly by discussing it (on the
> mysql-list I mean... there was an answer on bugtraq).
>
> I wrote my last mail just because I already confirmed that problem
> with 3.23 after I read bugtraq and therefore knew, that Sergei must
> have tested in a different way than me.
>
> But now I am upset about the fact, that obviously my post was not
> taken seriously. :-(
I do not think you were not taken seriously from what I read but the
example you gave was based on having access to both root and the
database admin accounts. If you lose control over these accounts that
you are in deep trouble. And this is not just for MySQL but for just
about any DB or other software package for that matter.
> My comments to your arguemnts follow below.
>
> Bye,
>
> Benjamin.
>
> On Wed, Mar 21, 2001 at 02:23:43PM +0200, [EMAIL PROTECTED] wrote:
> [...]
> > > newton:~> mysql -u root -e "select version()"
> > > +-----------+
> > > | version() |
> > > +-----------+
> > > | 3.23.33 |
> > > +-----------+
at this point you have lost contol of your system. you are running as
root and then "su" to mysql. Now you are the sysadmin for the mysql
package.
> > > 8:26:25 newton:~> sudo -u mysql touch /tmp/test # just created a file owned by
>mysql-user
> > > 8:26:45 newton:~> ln -sf /tmp/test /tmp/yikes.MYI
> > > 8:26:54 newton:~> ls -l /tmp
> > > [...]
> > > -rw-r--r-- 1 mysql mysql 0 Mar 21 08:26 test
> > > lrwxrwxrwx 1 philemon philemon 9 Mar 21 08:28 yikes.MYI -> /tmp/test
you created yikes.MYI as mysql. How is it that it is now owned by
philemon?
> > > 8:26:57 newton:~> mysql ../../../../tmp -e "create table yikes(w int(4))"
> > > 8:27:02 newton:~> ls -l /tmp
> > > [...]
> > > -rw-r--r-- 1 mysql mysql 1024 Mar 21 08:28 test
> > > -rw-rw---- 1 mysql mysql 0 Mar 21 08:28 yikes.MYD
> > > lrwxrwxrwx 1 philemon philemon 9 Mar 21 08:28 yikes.MYI -> /tmp/test
> > > -rw-rw---- 1 mysql mysql 8548 Mar 21 08:28 yikes.frm
> > >
> > > So, I have just overwritten a file not owned by me, namely /tmp/test.
> > > If mysql was running as root (which is of couse deprecated), I could
> > > overwrite any file in the system this way and even gain root access
> > > (as shown by someone on bugtraq), I think.
> > >
> > > Did I overlook something?
the point you are missing is that to do this you have to have root or
administrtor access. If this is a bug the same bug exists with Oracle
and Sybase. At the point when you do the "ln -s" you have lost control
of your system so the problem is not MySQL's but your general system
security. To put the point another way. The command rm has a bug. If I
am root I can remove a file that I do not own. Admitedly it is an
extreem example but the point is that if you lose control of root/admin
you are in deep trouble.
Now I would agree that you have a problem with MySQL if you were able to
create a table that pointed to an arbitrary location from within MySQL.
Also note that the /tmp/test created is owned by mysql it is not owned
by root or any other arbitrary user. and is not executable or writeable
by anybody but mysql.
> > >
> > > So, it looks to me, that at least 3.23.33 is not secure in this way (I
> > > have not compared 3.23.34 resp. 3.23.35 because for both problems were
> > > reported preventing them from use in production systems).
> > >
> > > Even without MySQL running as root, I can do a lot of harm (with
> > > privilege to create tables, I can probably gain MySQL root privileges,
> > > delete any other table, delete configs and log files and so on).
> > >
> > Running mysql as root is not safe.
>
> I did not presume running mysql as root. See above: The files are
> owned by user 'mysql'.
but you did persume to make your changes to the filesystem structure as
root or at the very least as the package admin.
>
> And I even explained which harm one can do with only getting
> mysql-user rights.
this is mysql admin rights. not regular mysql users.
> > Next, you had full shell access, with which you can accomplish
> > practically anything.
>
> Huh? That's new to me. I agree, that someone in the know almost always
> can find some way to gain root privileges if shell access is granted,
> but it is far more difficult than the two-liner above, which each
> script kiddie can use.
the point is correct. If you make the shell for the mysql user /bin/true
you cannot do what you wanted to without root access.
> You don't really want to compare that, do you?
You have missed the point.
> Btw, I don't need full shell access. I only need the possibility to
> create a link, for example a buggy CGI-script with www privileges
> which I can talk to executing ln -s /...
you have crafted an example that is sure to fail in real life. Anybody
who places there databases in /tmp is asking for trouble.
> This way two "harmless" bugs become a serious one.
>
> > Just take a look at passwd or shadow file, crack it and you can have
> > what ever you want.
>
> Well, the wit about shadow file is that it is *not* world readable. I
> always thought, that's what it's made for.
It just makes the problem a little more diffuclut to deal with. It is
not impossible to get access to the information in the file. If you lose
control of your passwords you are beat. plain and simple.
> In other words: on a properly secured system, it's not impossible, but
> a lot more difficult to do what you are talking about.
Now you are getting the point.
> I cannot really believe that you meant that stuff as a serious
> explanation that the bug shown above is not harmful.
once again it is not a bug. It is the way the OS works.
> > Last but not least, there is another matter. CREATE and FILE
> > privileges also should not be granted lightly.
>
> Of course, that why I was explicitly talking about the fact, that the
> user needs CREATE privileges (FILE privileges are not needed, If I am
> not mistaken).
If you can without becoming the "mysql user" and running a shell do what
you want. then you have found a real MySQL bug. For example try this
one. copy /bin/cp to /tmp/test before you create the database and
before you make the symbolic link. They try to re-run your test. You
should get different results
> ---------------------------------------------------------------------
> Before posting, please check:
> http://www.mysql.com/manual.php (the manual)
> http://lists.mysql.com/ (the list archive)
>
> To request this thread, e-mail <[EMAIL PROTECTED]>
> To unsubscribe, e-mail <[EMAIL PROTECTED]>
> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
--
Alvin Starr || voice: (416)585-9971
Interlink Connectivity || fax: (416)585-9974
[EMAIL PROTECTED] ||
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
