[MXS-4414] MaxScale logs passwords in SQL at the info level Created: 2022-11-25  Updated: 2022-12-13  Resolved: 2022-12-08

Status: Closed
Project: MariaDB MaxScale
Component/s: N/A
Affects Version/s: None
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Anurag Kumar (Inactive) Assignee: Johan Wikman
Resolution: Not a Bug Votes: 0
Labels: None
Environment:

MaxScale 22.08.2
xpand: 5.0.45-Xpand-6.1_beta1


Attachments: File maxscale.cnf    
Sprint: MXS-SPRINT-172

 Description   

When we issue a command that contains a password through maxscale using xpandmon.

  • xpand masks the password in xpand logs.
  • But, maxscale exposed the password in maxscale log at INFO level.

repro:
logged in to xpand via maxscale.

example 1: CREATE USER
executed query:

create user user1@'%' identified by 'user123$'

maxscale logs:

2022-11-25 06:32:24   info   : (13032) [readconnroute] (Read-Only-Service); Routed [COM_QUERY] to '@@Backend-Monitor:node-1' create user user1@'%' identified by 'user123$'

xpand logs:

2022-11-25 06:32:24.887883 UTC nid 1 karma016.colo.sproutsys.com clxnode: INSTR DDL SID:88065 db=test user=maxscale@10.2.16.27  ac=N xid=638061834d685002 sql="create user user1@'%' IDENTIFIED WITH mysql_native_password AS '*4D87A96B7E278BDA947ED2DF5FB2E06A56D38D49'" [no error] time 20.0ms commit_trx 6.0ms; found_rows: -1; fanout: no; attempts: 0; xpand: no

example 2: BACKUP

BACKUP db5391 TO 'sftp://qauser:password123@hefty.colo.sproutsys.com/tmp/tc5391/tc5391.bkup;

maxscale logs:

2022-11-25 06:33:32   info   : (13032) [readconnroute] (Read-Only-Service); Routed [COM_QUERY] to '@@Backend-Monitor:node-1' BACKUP db5391 TO 'sftp://qauser:password123@hefty.colo.sproutsys.com/tmp/tc5391/tc5391.bkup'

xpand logs:

2022-11-25 06:33:32.604425 UTC nid 1 karma016.colo.sproutsys.com clxnode: INSTR SQLERR SID:88065 db=test user=maxscale@10.2.16.27  ac=Y xid=638061cab6ca1002 sql="BACKUP db5391 TO 'sftp://qauser:<redacted>@hefty.colo.sproutsys.com/tmp/tc5391/tc5391.bkup'" [No such database: 'db5391'] time 1.0ms; row_count: -1; found_rows: -1; fanout: no; attempts: 0; xpand: no

example 3: RESTORE

RESTORE db5391 FROM 'sftp://qauser:password123@hefty.colo.sproutsys.com/tmp/tc5391/tc5391.bkup'

maxscale logs:

2022-11-25 06:34:23   info   : (13032) [qc_sqlite] (@@Backend-Monitor:node-1); Parsing the query failed, cannot report query type: RESTORE db5391 FROM 'sftp://qauser:password123@hefty.colo.sproutsys.com/tmp/tc5391/tc5391.bkup'

xpand logs:

2022-11-25 06:34:24.757753 UTC nid 1 karma016.colo.sproutsys.com clxnode: INSTR RESTORE SID:88065 db=test user=maxscale@10.2.16.27  ac=N xid=63806200b8400802 sql="RESTORE db5391 FROM 'sftp://qauser:<redacted>@hefty.colo.sproutsys.com/tmp/tc5391/tc5391.bkup'" [no error] time 1671.9ms begin_trx 21.0ms commit_trx 16.0ms; row_count: -1; found_rows: -1; fanout: no; attempts: 0; xpand: no



 Comments   
Comment by markus makela [ 2022-11-25 ]

MaxScale does not know what the semantics of the SQL are and thus passwords will be logged if the SQL contains them in plaintext. The same limitation applies to all sensitive data routed through MaxScale.

For the time being, I'd recommend not enabling the info log if the contents of the SQL are sensitive.

Comment by Johan Wikman [ 2022-12-08 ]

log_info is not intended to be kept on during normal operation (e.g. it significantly affects the performance), but only to be used when debugging problems. When doing that it is often important to be able to see the statements verbatim. Further, masking only passwords is tricky as it requires explicit knowledge of all places where passwords can occur.

So, do not have log_info on, unless there is an explicit need for that. When https://jira.mariadb.org/browse/MXS-3827 has been implemented, it will be possible to see after the fact whether someone has turned it on.

Closing this now as Not a bug. If you think this is important, please create a feature request for "secure mode" that then would cause all functionality that potentially can reveal passwords (log_info, retain_last_statements, session_trace, possibly QLA filter, etc.) to be disabled.

Generated at Thu Feb 08 04:28:28 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.