Audit_log_plugin is reading random memory

Bug #1437505 reported by monty solomon on 2015-03-27
256
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona Server moved to https://jira.percona.com/projects/PS
Fix Released
High
Sergei Glushchenko
5.5
Fix Released
High
Sergei Glushchenko
5.6
Fix Released
High
Sergei Glushchenko

Bug Description

This is an update to bug 1435606

I opened a new one since this may be a security vulnerability.

The plugin is reading random memory to use for the file name. I am not aware of an exploit.

Here are sample audit_log_file values from different servers.

@@audit_log_file
-------------\nEND OF INNODB MONITOR OUTPUT\n============================\n

@@audit_log_file
??

@@audit_log_file
?$?|

@@audit_log_file
ned DEFAULT NULL,\n PRIMARY KEY (`server_id`)\n) ENGINE=InnoDB DEFAULT CHARSET=l?'

@@audit_log_file
?

@@audit_log_file
?C
  ?

@@audit_log_file
?Hkz@@audit_log_file
v=\n

leted 31967587, read 343313943\n29.07 inserts/s, 32.57 updates/s, 0.00 deletes/s, 32.64 reads/s\n----------------------------\nEND OF INNODB MONITOR OUTPUT\n============================\n=?

@@audit_log_file
(255) DEFAULT NULL,\n `position` bigint(20) unsigned DEFAULT NULL,\n `relay_master_log_file` varchar(255) DEFAULT NULL,\n `exec_master_log_pos` bigint(20) unsigned DEFAULT NULL,\n PRIMARY KEY (`server_id`)\n) ENGINE=InnoDB DEFAULT CHARSET=latin1l_1529_0

@@audit_log_file
?Timestamp?Table_priv?Column_priv?

@@audit_log_file
N%?q

@@audit_log_file
active inside InnoDB\n0 RO transactions active inside InnoDB\n0 out of 1000 descriptors used\nMain thread process no. 5494, id 140048714626816, state: sleeping\nNumber of rows inserted 42, updated 11323367, deleted 26, read 11404807\n0.00 inserts/s, 11.07 updates/s, 0.00 deletes/s, 11.14 reads/s\n----------------------------\nEND OF INNODB MONITOR OUTPUT\n============================\n\n

@@audit_log_file
 `server_id` int(10) unsigned NOT NULL,\n `file` varchar(255) DEFAULT NULL,\n `position` bigint(20) unsigned DEFAULT NULL,\n `relay_master_log_file` varchar(255) DEFAULT NULL,\n `exec_master_log_pos` bigint(20) unsigned DEFAULT NULL,\n PRIMARY KEY (`server_id`)\n) ENGINE=InnoDB DEFAULT CHARSET=latin1

@@audit_log_file
 bigint(20) unsigned DEFAULT NULL,\n `relay_master_log_file` varchar(255) DEFAULT NULL,\n `exec_master_log_pos` bigint(20) unsigned DEFAULT NULL,\n PRIMARY KEY (`server_id`)\n) ENGINE=InnoDB DEFAULT CHARSET=latin1

This one looks very strange to me. Are you Percona Server user? What is your server version? Do you use audit plugin which comes with your version or you are using plugin from different version?

monty solomon (monty+launchpad) wrote :

Yes, Percona Server and the Percona Audit Log plugin.

The details are in bug 1435606.

Looks like upstream bug.

To reproduce

1. Run mysqld without audit plugin and without plugin options in my.cnf
2. Add plugin audit_log_file=/path/to/file.log into my.cnf
3. Install plugin with 'INSTALL ... ' command

audit_log_file now set to bogus value.

If you skip step 2, audit_log_file will be set to it's default value.
MySQL server re-reads my.cnf before installing new plugin, but fails to set correct value for 'audit_log_file' variable.

Changed in percona-server:
status: New → Confirmed
assignee: nobody → Sergei Glushchenko (sergei.glushchenko)
Changed in percona-server:
importance: Undecided → High
status: Confirmed → Triaged

Here is the in mysql_plugin_load:

  mysql_rwlock_wrlock(&LOCK_system_variables_hash);

  if (my_load_defaults(MYSQL_CONFIG_NAME, load_default_groups, &argc, &argv, NULL))
  {
    report_error(REPORT_TO_USER, ER_PLUGIN_IS_NOT_LOADED, name->str);
    goto err;
  }
  error= plugin_add(thd->mem_root, name, dl, &argc, argv, REPORT_TO_USER);
  if (argv)
    free_defaults(argv);
  mysql_rwlock_unlock(&LOCK_system_variables_hash);

Memory allocated to store variables released and audit_log_file
points to memory heap which can be used for other purposes.

To avoid this we should use PLUGIN_VAR_MEMALLOC flag.
Quote from commens in sql_plugin.cc:

  Most plugin variable values are stored on dynamic_variables_ptr.
  Releasing memory occupied by these values is as simple as freeing
  dynamic_variables_ptr.

  An exception to the rule are PLUGIN_VAR_MEMALLOC variables, which
  are stored on individual memory hunks. All of these hunks has to
  be freed when it comes to cleanup.

Adding PLUGIN_VAR_MEMALLOC resolves the issue.

information type: Private Security → Public Security

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-887

To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers