mailing list archives
Re: CVE request: multiple vulnerabilities in dtc
From: Thomas Goirand <thomas () goirand fr>
Date: Sat, 13 Aug 2011 09:50:43 +0800
We are discussing the issues with Philippe Kern. While there are issues
that were discovered, I am claiming that some of what you see below
shouldn't be in the list.
On 08/13/2011 05:26 AM, Jonathan Wiltshire wrote:
dtc saves the administrator password in plain text in
/var/lib/dtc/saved_install_config under the variable name conf_adm_pass.
It remains there even after initial configuration.
That's not more a security vulnerability than /etc/mysql/debian.cnf
(both file are readable by root only). This has been in the BTS for a
long time, and it makes no sense to assign a CVE now.
dtc-xen includes several command executions as root that use unchecked
user input in dtc-soap-server.
That's not relevant and isn't a vulnerability. I have closed the bug a
long time ago, writing that I wont fix it, and explaining why. Please
see the BTS entry for it. dtc-xen isn't supposed to run stand-alone, and
the only client for dtc-xen is dtc itself. If you gain access to it,
then there is an issue somewhere else, and "fixing" things here wont
make things better.
dtc stores user passwords and passwords for various services in unencrypted
form in the database.
This is fixed in the Git, and has already been discussed. While it's a
serious issue (which has been carefully worked on), it didn't deserve a
CVE 6 months ago, and it shouldn't right now.
Insufficient input checking in /shared/inc/sql/lists.php
The setup script for dtc writes the password for the MySQL user in the
world-readable file /etc/apache2/apache2.conf.
Insufficient input checking leads to a SQL injection vulnerability in
A SQL injection vulnerability in logPushlet.php can overwrite arbitrary
files as the MySQL system user.
dtc passes passwords to htpasswd using command line arguments, which can be
read by a local user.
dtc does not escape variables in HTML output in many places; for example
in the "Domain root TXT record:" field on the "DNS and MX" page where
The above should be fixed and are real issues, but what I commented
don't deserve a CVE.
Note that these descriptions are mostly taken from the bug reports and may
not be suitable for direct publication without editing. I have checked as
far as possible that none of these were previously assigned CVEs but they
could be duplicates. There are often mitigating factors such as
user or administrator authentication.
Absolutely all of them need a user to be logged indeed.