[MDEV-9042] CREATE USER passwords being written to bin log in clear text Created: 2015-10-30  Updated: 2023-11-30

Status: Open
Project: MariaDB Server
Component/s: Admin statements
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Mark Punak Assignee: Sergei Golubchik
Resolution: Unresolved Votes: 1
Labels: security, upstream-fixed

Issue Links:
Duplicate
duplicates MDEV-28016 CREATE USER replicated with clear tex... Closed
is duplicated by MDEV-9016 Account Management Commands being wri... Closed
is duplicated by MDEV-10584 Obscure plain text passwords from ser... In Review
is duplicated by MDEV-20182 User Password Display in Error Closed
is duplicated by MDEV-24032 Password's are getting logged in the ... Closed

 Description   

Issuing a CREATE USER command on a MariaDB 10.0 database setup for row based replication using GTID causes the statement to be written to the binlog in clear text, a security risk.

– From the binlog:

#151026 12:37:44 server id 122  end_log_pos 1071839282  Query   thread_id=58251 exec_time=0     error_code=0
SET TIMESTAMP=1445888264/*!*/;
SET @@session.pseudo_thread_id=58251/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=0/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
CREATE USER 'testuser'@'%' IDENTIFIED BY 'my_password_in_clear_text'
/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

######################################

relevant settings from my.cnf.d/server.cnf

--------------------------------------------
#-----------------------------------
# MASTER REPLICATION OPTIONS
#-----------------------------------
server_id =                                     122
gtid-domain-id=                                 0
 
log-bin=                                        mariadb.bin
log-basename=                                   ds
binlog-do-db=                                   positioning
binlog-format=                                  ROW
sync_binlog =                                   1
 
#-----------------------------------
# SLAVE REPLICATION OPTIONS
#-----------------------------------
relay-log-index =                               relay-bin.index
relay-log =                                     relay-bin
 
replicate-events-marked-for-skip=               FILTER_ON_MASTER
replicate-do-db=                                positioning
 
log-slave-updates=                              1
gtid-strict-mode=                               1
 
slave_skip_errors =                             all
innodb_flush_log_at_trx_commit=                 1
 
slave_parallel_threads =                        4
slave_parallel_max_queued=                      100031072



 Comments   
Comment by Elena Stepanova [ 2015-10-30 ]

It was fixed in MySQL 5.6, but in MariaDB it is still the case.
I'm setting the Fix version to 10.1 to keep it on the radar, although I'm not sure it can be done in a GA release.

Comment by Sergei Golubchik [ 2016-03-15 ]

It cannot
I've changed it to a "Task"

Comment by Sergei Golubchik [ 2018-10-11 ]

Why is it a security risk? What is a use case?

Comment by Yogesh [ 2023-08-31 ]

This is a security risk because if an attacker gets access to the disk containing the binlogs then they can access the database using these plaintext credentials. What's the plan to fix this in Mariadb?

Comment by Sergei Golubchik [ 2023-09-01 ]

If the attacker gets access to the disk containing the binlogs then they will see all the data in binlog anyway, and most likely all the data in the datadir too. The solution to this should be to encrypt binlogs (and possibly datadir) using https://mariadb.com/kb/en/encryption-data-at-rest-encryption/

Generated at Thu Feb 08 07:31:42 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.