Bug #46381 Security Flaw: history is kept cross-user cross-shell-session
Submitted: 25 Jul 2009 2:34 Modified: 27 Jul 2009 3:51
Reporter: Roel Van de Paar Email Updates:
Status: Won't fix Impact on me:
None 
Category:MySQL Server: Command-line Clients Severity:S1 (Critical)
Version:5.1.34, 5.5 OS:Any
Assigned to: CPU Architecture:Any

[25 Jul 2009 2:34] Roel Van de Paar
Description:
Scenario: user forgets pwd. admin walks over to user and signs in as root (or a privileged admin user) to mysqld, and changes the user's pwd. At the same time he gets a ring on his cell phone - a manager has lost his pwd, so he changes it at the same time using SET PASSWORD. He closes the mysql client and the shell session, and hands the pc back to the user, assuming he's done everything he needs to do. User opens another shell session, logs in to mysql as his own account, presses cursor-up a few times and voila he's got the managers pwd.

This scenario is possible today.

On Windows, the same is possible (tested in 5.1.35), if the administrator did not close the command session, even if he logged out of the mysql client.

How to repeat:
============
roel@roel-ubuntu-vm:~$ cd /mysql/mysql-5.1.34-linux-i686-icc-glibc23/
roel@roel-ubuntu-vm:/mysql/mysql-5.1.34-linux-i686-icc-glibc23$ cd bin
roel@roel-ubuntu-vm:/mysql/mysql-5.1.34-linux-i686-icc-glibc23/bin$ ./mysql -uroot -p -h127.0.0.1 -P5134
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 11
Server version: 5.1.34 MySQL Community Server (GPL)

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> SET PASSWORD FOR 'rtest'@'%' = PASSWORD('resetpwd');
Query OK, 0 rows affected (0.00 sec)

mysql> SET PASSWORD FOR 'manager'@'%' = PASSWORD('somepwd');
Query OK, 0 rows affected (0.00 sec)

mysql> exit 
Bye
roel@roel-ubuntu-vm:/mysql/mysql-5.1.34-linux-i686-icc-glibc23/bin$ exit
============ <shell session terminated>

Admin walks away, user opens a new shell session, logins to mysql and presses 'cursor up' a few times:

============
roel@roel-ubuntu-vm:~$ cd /mysql/mysql-5.1.34-linux-i686-icc-glibc23/bin/
roel@roel-ubuntu-vm:/mysql/mysql-5.1.34-linux-i686-icc-glibc23/bin$ ./mysql -urtest -p -h127.0.0.1 -P5134
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 14
Server version: 5.1.34 MySQL Community Server (GPL)

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> SET PASSWORD FOR 'manager'@'%' = PASSWORD('somepwd');
============

For windows, it's the same, but history is only kept until the cmd box is closed. More secure, but still an issue.

Suggested fix:
Resolve security issue.

This bug is not the same as bug #1423. This issue cannot be prevented by setting correct rights for .mysql_history as described here:
http://dev.mysql.com/doc/refman/5.1/en/password-security-user.html
http://dev.mysql.com/doc/refman/5.1/en/mysql-command-options.html#id724385
[25 Jul 2009 16:08] Valeriy Kravchuk
Sorry, but in your example in both cases roel@ UNIX account was used. 

Normal administrator will log in as himself at OS level or will use su/sudo at least if not to (UNIX) root then to his own account. Why should he work from user's UNIX account, especially when solving security-related problems?

Same case with cmd.exe - why normal admin would use user's cmd.exe instead of opening another one (maybe from his own OS account) and closing it after finishing his actions?

I think this example is artificial and normal security practices will prevent these features from abuse. Not a bug, IMHO.
[25 Jul 2009 16:24] Sergei Golubchik
Scenario: user complains that his coffee cup holder is broken, admin walks in to explain what a cd drive is. At the same time he gets a ring on his cell phone - a manager wants a wallpaper on his desktop changed, he writes down the password (that manager told him over the phone), logs in to the manager computer and changes the wallpaper. Then he fixes the user's cd and hands the pc back to the user, assuming he's done everything he needs to do. User goes to his table, peeks into the piece of paper that the admin forgot and voila he's got the managers pwd.

That's pretty much the same scenario.

Not a bug.
[27 Jul 2009 2:55] Roel Van de Paar
> Sorry, but in your example in both cases roel@ UNIX account was used. 

Yes, I am aware of this, this is one of the considerations in this bug.

> Normal administrator will log in as himself at OS level or will use su/sudo at least if not to (UNIX) root then to his own account. Why should he work from user's UNIX account, especially when solving security-related problems?

Why would an admin log in at the OS level if the mysql client binary is available *right there*? 

> Same case with cmd.exe - why normal admin would use user's cmd.exe instead of opening another one (maybe from his own OS account) and closing it after finishing his actions?

Similar/same question: why would an admin logout the user (closing everything the user has open) and login as his own ID, if the mysql client binary is available to be used *right there*? 

Even if the 'Run As' functionality is enabled/available (http://support.microsoft.com/kb/294676), why would an administrator use it, especially if he is expecting the mysql application to be secure? More on this below.

> I think this example is artificial and normal security practices will prevent these features from abuse. 

Yes, the example is artificial, but it was used to highlight a security flaw in the way that .mysql_history is designed.

Should proper security for MySQL not start at the application layer, rather than the OS layer?

> Not a bug, IMHO.

Consider how Linux does this: when you type 'exit' from 'su' in Unix - the commands you entered while in 'su' mode, are not available to the user id used to invoke 'su'. (And, they should not be, because that would be a security flaw, of the same type as the one being described here.)

A solution would be to store the history in a database on the MySQL server with proper (and automatic) GRANTS for each user. This way one user's history would never be visible to another (unless you're an administrator): this would be proper application level security.

At the very least, this could be considered a feature request.
[27 Jul 2009 3:05] Davi Arnaut
> Why would an admin log in at the OS level if the mysql client binary is available *right there*? 

and there is absolutely nothing we can make to guarantee it's our mysql client binary. User could alias mysql to a script that logs all input and pipes it to a real mysql client binary.

Whatever a admin does through the user account is not secure, all bets are off.
[27 Jul 2009 3:26] Roel Van de Paar
> Whatever a admin does through the user account is not secure

I agree 100%, though that should not stop us from making the mysql client as secure as possible.

How about my proposed solution/feature request?
[27 Jul 2009 3:51] Valeriy Kravchuk
If you mean this solution:

"A solution would be to store the history in a database on the MySQL server with proper (and automatic) GRANTS for each user. This way one user's history would never be visible to another (unless you're an administrator): this would be proper application level security."

it is possible to implement, but it will put additional load on server, pollute server's mysql "metadata", put additional load on DBA to manage history table(s) properly etc. It is more like an "audit feature implementation" at server level, that we already have in a form of general query log...

Also it will not allow (or will make it complex) to get cross-server history. Now client remembers all the commands executed from it, whatever MySQL server and (MySQL) user names are used, and it is very useful in some cases. I use this a lot personally.

To summarize: client's commands history belongs to client. I see no need to implement new feature at server level for adiministrators who do not care about simplest security practices.
[27 Jul 2009 13:10] Davi Arnaut
> How about my proposed solution/feature request?

I somewhat understand your concern, but this scenario does not yield sufficient value to warrant the efforts required to build such a solution.

A acceptable solution with minimal effort would be to implement something similar to bash's HISTIGNORE -- a list of patterns used to decide which commands to not save to history. Another option is to add a --no-history switch to prevent a myqsl client session from saving any commands to the history.

Such feature requires minimal effort, makes sense in a few scenarios and might address your concern. If you agree, please open a new bug report requesting this feature. But please don't mention this bug scenario, it doesn't help your case.
[20 Jun 2011 9:08] Valeriy Kravchuk
Bug #61564 was marked as a duplicate of this one.