Skip to content

.mylogin.cnf password recovery

As Todd Farmer points out in Understanding mysql_config_editor’s security aspects, the new .mylogin.cnf file generated by mysql_config_editor does not securely store the password used to login to the database. It just obfuscates it.

The format of the file is as follows (as of MySQL 5.6.7-RC):
  • 4 Bytes Zero (Version Information)
  • 20 Bytes Key Generation Matter
  • Repeated:
    • 4 Bytes Length information
    • Length bytes crypted matter. The crypt is done using the AES ENCRYPT function, which in itself is insecure: It is an aes-128-ecb with a NULL IV.


The key used by AES 128 needs to be CHAR(16), but the function accepts any string as a key generation matter. It generates the key from the key generation matter by xor-ing the key generation matter onto itself in a 16 byte loop, starting with a buffer of NULL bytes.

In Code: Continue reading ".mylogin.cnf password recovery"

pam modules for MySQL: What is wrong with these people?

Percona just released their MySQL PAM Authentication insanity, just as Oracle did before, for MySQL 5.5 and MariaDB is no better.

The Oracle module requires a module to be loaded into your client, which is done automatically if the module is present and the server supports PAM auth. The module is called ominously "mysql_clear_password" and does what it says on the tin: Your database server access password is henceforth sent from the client to the server in clear, not encrypted, hashed, salted or otherwise protected.

I suppose the Percona module does the same, although it is not being mentioned in the docs at all (or at least I have not been able to find it in there). They also openly suggest to run the database server as root, as that is the only way for an in-process PAM auth module to be able to access /etc/shadow.

*headdesk*

Does any of you know what SASL is and why it has been invented?

I know it's a pain, but it is there for a reason. Many reasons. saslauthd for example will read your authentication secrets instead of your worker process, because you are unable to write and maintain a secure codebase the size of a database server. And by speaking SASL on the wire and then handing off an authenticated connection to your actual worker code you gain access to a number of integrated mechanisms for communicating passwords in a compatible and secure manner, none of which include clear text passwords on the wire.

Can we please bury these plugins, deeply in the Mariana trench, in a CASTOR, put a warning beacon over the site and then start over, doing it right this time?

Thanks. I knew you would see the light eventually.

Heise Security: Buffer Overflow in MySQL

Heise Security writes about the UDF Buffer Overflow in MySQL (CAN-2005-2558).

The bug is fixed in 4.0.25, 4.1.13 and 5.0.7 (beta). It is exploitable only if
  • your MySQL port is reachable,
  • and you are authenticated,
  • and you have permission to execute create function. To be able to do this, you need INSERT privilege on the mysql.func table, that is, you usually are already root on your server.
The bug is consequently considered not critical.

System integrators that provide MySQL as part of their distributions are following suit with their respective advisories and provide upgrades.

More background information: The term user defined function describes the ability of the MySQL server to load and execute machine code at run-time within the context of the MySQL server. This code is made available to the end user in the form of SQL functions that can be called in SELECT and other commands. Security is implemented by restricting the pathnames from which code can be loaded, but UDF permission still is an extremely far reaching access right, and is not granted by default to anybody except the DBA.

Should you upgrade? The upgrade to a current version of MySQL is recommended, but is critical in your environment only, if the above three conditions for an exploit are met by users you deem untrustworthy within the terms of your security policy.