Bug #649 A security bug of Replication
Submitted: 13 Jun 2003 0:12 Modified: 13 Jun 2003 6:11
Reporter: zhang tao Email Updates:
Status: Not a Bug Impact on me:
None 
Category:MySQL Server: Replication Severity:S1 (Critical)
Version:4.0.12 OS:Windows (Windows2000)
Assigned to: CPU Architecture:Any

[13 Jun 2003 0:12] zhang tao 
Description:
The password in file:"master.info" is not encrypted.So everyone can get the username and password  easily.

How to repeat:
Set up a Master Server and Slave server according to the "4.10.3 How To Set Up Replication" in Mysql document.File:"master.info" is under mysql\data\

Suggested fix:
The password in file:"master.info" should be encrypted.
[13 Jun 2003 6:11] Guilhem Bichot 
Hi,

For sure you are right, the password that the slave uses to connect to the master is written unencrypted to the master.info file in the slave's directory.
But this does not open a new security fault in your system.
Because if a Windows user is able to read master.info and steal the password, then all he can do is set up a MySQL slave on another machine and make it replicate the master, thus getting a copy of all the master's data. 
So getting the password means getting a copy of the master's data (it should not mean more; we recommend in our manual to give only the REPLICATION SLAVE privilege to the replication user, no other privilege, so this user cannot be used to modify the master's databases).
But being able to read master.info also means the Windows user has permissions on the directory where this file is, the data directory, and so he has permissions on the slave's table files (files of extension FRM/MYI/MYD which are in subdirectories of the data directory), which are copies of the master tables.
This is why I say that the unencryption of master.info does not give a nasty Windows user more control than he already has: if he was able to read master.info then it implies he already could have a copy of the master's data without even reading master.info.
To make your system secure, I would recommend you set up permissions on the slave's data directory: assuming the slave MySQL runs as user SYSTEM (that's common if you installed MySQL as a service), no Windows user should have any permission (no READ, no WRITE) on the data directory and its subdirectories, except the SYSTEM user (and the Administrators, which have all permissions anyway).

It is true with all RDBMS that OS-level permissions have to be carefully tuned to not open security faults in the database. As an example, Oracle DBAs know they should never give access to the 'orapwd' and 'oradim' executables to any Windows user, because these can be used to change the password of the 'internal' user, giving the attacker full database-level privileges.

Regards,
Guilhem