Greetings,
I have discovered an exposure in the history recall functionality of
MySQL Monitor. When a user uses MySQL monitor authenticated as the
database root user to issue commands, such as changing user passwords or
database table creation, that history can be recalled by a database user
of lesser privileges. This exposes passwords and table structure, which
may not want to be exposed. This happens because the MySQL Monitor
history is stored in the invoking Unix user's home directory. Likewise,
that Unix user can simply cat the history file (cat .mysql_history) and
see the commands, like this:
aaron:~ $ cat .mysql_history
select * from user;
select Host,User,Password from user;
update user set Password=password("secret1") where User="root";
select Host,User,Password from user;
Tying the MySQL Monitor history to a particular Unix user may be thought
to be secure, but it is not. Many companies use specific ID's to
perform specific work. In these examples, the user will log in under
their own ID, and su over to the surrogate ID to perform a task which
that ID is allowed to conduct. If a users decides to perform MySQL
administration (as MySQL root user) while logged into that surrogate ID,
anyone else who has access to that surrogate ID now has access to all of
the MySQL commands issued by that Unix user.
Granted, this exposure only manifests itself in situations where
previously existing security practices are poor, however, why should
MySQL reveal information needlessly? The history should be tied to the
MySQL user who has authenticated to MySQL, not the Unix user account
accessing mysql. I wish I could say nobody engaged in the above
practice, but, I know better.
I tried this on MySQL-Max 3.23.54 and 3.23.54a under Slackware 8.1 and
SuSE 8.1. It happens only when logging into the database server
itself. Using mysql and connecting to a remote MySQL server puts the
history into the local Unix user's .mysql_history file.
I rate this as a low impact security exposure because it is a downstream
consequence of improper security practices.
Thank you for your consideration.
Regards,
George Toft
---------------------------------------------------------------------
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
