Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri,  7 Aug 2015 13:04:19 -0400 (EDT)
Subject: Re: CVE request: Froxlor - information leak

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 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',

> - replace passwords even before logging:

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:

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 ]
Version: GnuPG v1


Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ