Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.2.18, 10.3.10
-
None
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.
Attachments
Issue Links
- relates to
-
MDEV-19459 Backport MDEV-17456 to server_audit plugin in 10.1
-
- Closed
-
-
-
- Closed
-
-
-
- Open
-
Activity
| Field | Original Value | New Value |
|---|---|---|
| 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.: {{noformat}} SET global server_audit_logging=0; {{noformat}} 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 {{noformat}} [mysqld] server_audit_immutable=ON {{noformat}} that could be used to remove the {{DYNAMIC}} attribute from all audit plugin variables, and so to prevent runtime changes to audit log configuration. |
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.: {noformat} SET global server_audit_logging=0; {noformat} 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 {noformat} [mysqld] server_audit_immutable=ON {noformat} that could be used to remove the {{DYNAMIC}} attribute from all audit plugin variables, and so to prevent runtime changes to audit log configuration. |
| Fix Version/s | 10.2 [ 14601 ] | |
| Fix Version/s | 10.3 [ 22126 ] | |
| Assignee | Sergei Golubchik [ serg ] |
| Assignee | Sergei Golubchik [ serg ] | Alexey Botchkov [ holyfoot ] |
| Summary | Malicous SUPER user can possibly change audit log configuration without leaving traces | Malicious SUPER user can possibly change audit log configuration without leaving traces |
| Fix Version/s | 10.4 [ 22408 ] |
| Status | Open [ 1 ] | In Progress [ 3 ] |
http://lists.askmonty.org/pipermail/commits/2019-April/013696.html
The SET server_audit_logging=off statement has to be logged always.
| issue.field.resolutiondate | 2019-04-28 22:07:52.0 | 2019-04-28 22:07:52.087 |
| Fix Version/s | 10.2.24 [ 23308 ] | |
| Fix Version/s | 10.2 [ 14601 ] | |
| Fix Version/s | 10.3 [ 22126 ] | |
| Fix Version/s | 10.4 [ 22408 ] | |
| Resolution | Fixed [ 1 ] | |
| Status | In Progress [ 3 ] | Closed [ 6 ] |
| Fix Version/s | 10.3.15 [ 23309 ] | |
| Fix Version/s | 10.4.5 [ 23311 ] |
| Link |
This issue relates to |
| Link | This issue relates to MDEV-14713 [ MDEV-14713 ] |
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.
holyfoot See the last inputs from Support, this is unfortunately not fixed yet for customers.
| Resolution | Fixed [ 1 ] | |
| Status | Closed [ 6 ] | Stalled [ 10000 ] |
| Status | Stalled [ 10000 ] | In Progress [ 3 ] |
| issue.field.resolutiondate | 2019-05-19 20:34:45.0 | 2019-05-19 20:34:45.656 |
| Fix Version/s | 10.3.15 [ 23309 ] | |
| Fix Version/s | 10.4.5 [ 23311 ] | |
| Resolution | Fixed [ 1 ] | |
| Status | In Progress [ 3 ] | Closed [ 6 ] |
| Fix Version/s | 10.4.6 [ 23412 ] | |
| Fix Version/s | 10.3.16 [ 23410 ] |
| Fix Version/s | 10.2.25 [ 23408 ] | |
| Fix Version/s | 10.2.24 [ 23308 ] |
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.
| Workflow | MariaDB v3 [ 90103 ] | MariaDB v4 [ 155059 ] |
| Zendesk Related Tickets | 168572 |
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.