Date: Fri, 7 Aug 2015 13:04:19 -0400 (EDT) From: cve-assign@...re.org To: oss-security-list@...lak.de Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: CVE request: Froxlor - information leak -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > An unauthenticated remote attacker is able to get the database password > via webaccess due to wrong file permissions of the /logs/ folder in > froxlor version 0.9.33.1 and earlier. The plain SQL password and > username may be stored in the /logs/sql-error.log file. This directory > is publicly reachable under the default configuration/setup. > > The certain section looks like this: > > /var/www/froxlor/lib/classes/database/class.Database.php(279): > PDO->__construct('mysql:host=127....', 'DATABASE_USER', > 'PLAIN_DATABASE_PW', Array) > - replace passwords even before logging: > > https://github.com/Froxlor/Froxlor/commit/8558533a9148a2a0302c9c177abff8e4e4075b92 Based on the code changes, it appears that the most important vulnerability is that the password was logged (regardless of where it was logged). Use CVE-2015-5959 for this issue. >> $error_message = str_replace($sql['password'], 'DB_UNPRIV_PWD', $error_message); Presumably this is considered sufficient because a properly chosen password is unlikely to occur elsewhere in the error message. (Otherwise, it might be possible to determine the password by looking for any error message that contains the substring "DB_UNPRIV_PWD" more than once.) The use of syslog rather than logs/sql-error.log does not, by itself, seem to be an independent vulnerability fix because the documentation doesn't mention setting the permissions of the file that will store syslog LOG_LOCAL0 messages. Also, not using syslog was apparently intentional: lib/classes/database/class.Database.php says "log to a file, so we can actually ask people for the error (no one seems to find the stuff in the syslog)." > - log db errors to syslog instead of /logs/sql-error.log file: > > https://github.com/Froxlor/Froxlor/commit/4ec376b29671593a50556630551e04e34bc83c1c If you are also reporting this as a vulnerability, please let us know and we can assign another CVE ID for the issue that the log was available remotely (regardless of whether it contained a password). [ Finally, it seems somewhat unusual that the security fix leads to the deletion of the existing logs/sql-error.log file, possibly without documenting that that will happen. This step is potentially useful in the sense that the password might already be present in that file. In some cases, a customer would prefer manual instructions for cleanup of an information leak, either because the logs/sql-error.log file has other useful information, or because the customer actually needs to know whether the password was ever present there. Typically, CVE IDs are not used for issues about whether, or how, a vulnerability fix attempts to address an already-triggered vulnerability. ] - -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington Road, Bedford, MA 01730 USA [ PGP key available through http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVxOTKAAoJEKllVAevmvmsM2EH/Rlms397iuOVH0d3Tdd5XASB yYVPQT8rUUMVKteAM+Zja8Xwdco0koGhf+htrxz5trmxSW8xOr+QtcUM6D5qy9N/ 7n+/nEdDNeXKQMq69Ui1pAeQW1p1cvhdHPDZymMEAvQDEfaLOjxjpNgWxggeSQ3+ 3GI+cIEMBLmqDt/NlnKjAExDGgZGYEyacZvhTUJwILfFr1w3ZNvhxysZagx6tRUt J+2O2pfXGez7gG21ehP44+HX0f9w8dWYHHDbZppqr2H338nDDez4z8DxBaH9z8Ip nfRxOFXmyUAsbAGXCZ2rKWrPXb2SG9O/G1jUTGE2pshKh0fR7SThGDBAB28Ui9Y= =I3Yv -----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ