[MDEV-17456] Malicious SUPER user can possibly change audit log configuration without leaving traces Created: 2018-10-15  Updated: 2020-08-25  Resolved: 2019-05-19

Status: Closed
Project: MariaDB Server
Component/s: Plugin - Audit
Affects Version/s: 10.2.18, 10.3.10
Fix Version/s: 10.2.25, 10.3.16, 10.4.6

Type: Bug Priority: Major
Reporter: Hartmut Holzgraefe Assignee: Alexey Botchkov
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-19459 Backport MDEV-17456 to server_audit p... Closed
relates to MDEV-5983 Auditing plugin v2.0 Closed
relates to MDEV-14713 MariaDB Audit Plugin audits SET GLOBAL Open

 Description   

SET queries are only logged in the audit log when server_audit_events=QUERY is set, not with the more specific QUERY_* sub-modes.

So when e.g. using server_audit_events=QUERY_DCL queries that change the logging behavior, like e.g.:

SET global server_audit_logging=0;

This way a malicious user with SUPER privileges (but without file system level access to the server config files) could temporarily disable audit logging and then modify data without leaving a real trace.

IMHO queries changing the audit log configuration, so any SET operating on a server_audit_% variable, should appear in the log even if full QUERY mode is not set, or at least be included in QUERY_DCL mode.

Or, alternatively, there should be an option to outright ban any dynamic change of server_audit_% variables, e.g. something like

[mysqld]
 
server_audit_immutable=ON

that could be used to remove the DYNAMIC attribute from all audit plugin variables, and so to prevent runtime changes to audit log configuration.

 Comments   
Comment by Elena Stepanova [ 2018-10-15 ]

Assigned to serg to decide how we conceptually deal with the idea of "malicious SUPER user" from the security point of view. After that it will probably go to holyfoot.

Comment by Alexey Botchkov [ 2019-04-28 ]

http://lists.askmonty.org/pipermail/commits/2019-April/013696.html

The SET server_audit_logging=off statement has to be logged always.

Comment by Geoff Montee (Inactive) [ 2019-05-16 ]

Since the server_audit_% system variables can affect the audit logging configuration, it may be a good idea to make "SET GLOBAL" followed by any server_audit_% system variable a special case that is always logged, regardless of the value of server_audit_events. See also MDEV-14713 for a related request.

Comment by Julien Fritsch [ 2019-05-17 ]

holyfoot See the last inputs from Support, this is unfortunately not fixed yet for customers.

Comment by Alexey Botchkov [ 2019-05-19 ]

http://lists.askmonty.org/pipermail/commits/2019-May/013791.html

Comment by Geoff Montee (Inactive) [ 2019-06-21 ]

I executed the following queries in MariaDB 10.2.25:

MariaDB [(none)]> INSTALL SONAME 'server_audit';
 
Query OK, 0 rows affected (0.01 sec)
 
 
 
MariaDB [(none)]> SET GLOBAL server_audit_events='CONNECT';
 
Query OK, 0 rows affected (0.00 sec)
 
 
 
MariaDB [(none)]> SET GLOBAL server_audit_logging=ON;
 
Query OK, 0 rows affected (0.00 sec)
 
 
 
MariaDB [(none)]> SET GLOBAL server_audit_logging=OFF;
 
Query OK, 0 rows affected (0.00 sec)
 
 
 
MariaDB [(none)]> SET GLOBAL server_audit_logging=ON;
 
Query OK, 0 rows affected (0.00 sec)
 
 
 
MariaDB [(none)]> SET GLOBAL server_audit_logging=OFF;
 
Query OK, 0 rows affected (0.00 sec)
 
 
 
MariaDB [(none)]> SET GLOBAL server_audit_excl_users='bob';
 
Query OK, 0 rows affected (0.00 sec)
 
 
 
MariaDB [(none)]> SET GLOBAL server_audit_logging=ON;
 
Query OK, 0 rows affected (0.00 sec)
 
 
 
MariaDB [(none)]> SET GLOBAL server_audit_excl_users='bob,alice';
 
Query OK, 0 rows affected (0.00 sec)
 
 
 
MariaDB [(none)]> \q
 
Bye

The audit log only contains the following:

20190621 16:59:27,ip-172-30-0-58.us-west-2.compute.internal,root,localhost,14,5,QUERY,,'SET GLOBAL server_audit_logging=OFF',0
 
20190621 16:59:29,ip-172-30-0-58.us-west-2.compute.internal,root,localhost,14,7,QUERY,,'SET GLOBAL server_audit_logging=OFF',0
 
20190621 17:00:16,ip-172-30-0-58.us-west-2.compute.internal,root,localhost,14,0,DISCONNECT,,,0

So it does not look like this has been fixed yet.

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