From: Matthijs Kooijman <matthijs@stdin.nl>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: bacula-director-mysql: Database password for catalog backups out in the open
Date: Mon, 15 Oct 2007 22:10:53 +0200
Package: bacula-director-mysql; Maintainer for bacula-director-mysql is Debian Bacula Team <pkg-bacula-devel@lists.alioth.debian.org>; Source for bacula-director-mysql is src:bacula (PTS, buildd, popcon).
Reported by: Matthijs Kooijman <matthijs@stdin.nl>
Date: Mon, 15 Oct 2007 20:12:01 UTC
Severity: important
Tags: patch, security, upstream
Done: John Goerzen <jgoerzen@complete.org>
Bug is archived. No further changes may be made.
Forwarded to http://bugs.bacula.org/view.php?id=990
View this report as an mbox folder, status mbox, maintainer mbox
Report forwarded to debian-bugs-dist@lists.debian.org, John Goerzen <jgoerzen@complete.org>:
Bug#446809; Package bacula-director-mysql.
(full text, mbox, link).
Acknowledgement sent to Matthijs Kooijman <matthijs@stdin.nl>:
New Bug report received and forwarded. Copy sent to John Goerzen <jgoerzen@complete.org>.
(full text, mbox, link).
Message #5 received at submit@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Package: bacula-director-mysql Severity: important Tags: patch, security Hi, the default bacula configuration file supports backing up the catalog database using the "make_catalog_backup" script. For this, the following line is in bacula-dir.conf: RunBeforeJob = "/etc/bacula/scripts/make_catalog_backup bacula bacula" If the database is password protected, the password must be added as a third argument. This works as expected, but poses up a number of security risks. Firstly, when the backup fails, the complete command line is put into an email with the error messages, including the password. For example: 15-Oct 21:10 stdio.flexvps.nl-dir: BeforeJob: run command "/etc/bacula/scripts/make_catalog_backup bacula bacula c1130ee16f7125579d6214bcd114b71" 15-Oct 21:10 stdio.flexvps.nl-dir: BeforeJob: mysqldump: Got error: 1045: Access denied for user 'bacula'@'localhost' (using password: YES) when trying to +connect Since email is no secure channel, this can expose the database password. Having the database password in the error message hardly serves any purpose and should probably be avoided. Additionally, having the password on the commandline, makes it available to users on the same machine. The command lines of running processes are usually accessible to users, so running a simple matthijs@stdio:~$ ps aux|grep catalog bacula 11706 0.0 0.0 4092 1452 ? S 21:43 0:00 /bin/sh /etc/bacula/scripts/make_catalog_backup bacula bacula 0c1130ee16f7125579d6214bcd114b71 reveals the database password. It would be better to store the password in an external file, and pass that filename to the make_catalog_backup script. In this way, the make_catalog_backup script is still generic, but the database password is not exposed (though that file should be readable by the bacula user, not only by root). The attached patch achieves the above, while maintaining backwards compatibility. It might be better to remove backwards compatibility to prevent users from using the old, insecure way, however. Additionally, my modifications to the script could pose problems if someone uses a database password that is also the name of an existing file. Gr. Matthijs -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.23-rc9-g1b60e5d0-dirty (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages bacula-director-mysql depends on: pn bacula-director-common <none> (no description available) pn dbconfig-common <none> (no description available) ii debconf [debconf-2.0] 1.5.14 Debian configuration management sy ii libc6 2.6.1-1 GNU C Library: Shared libraries ii libgcc1 1:4.2.1-4 GCC support library ii libmysqlclient15off 5.0.45-1 MySQL database client library ii libstdc++6 4.2.1-4 The GNU Standard C++ Library v3 ii libwrap0 7.6.dbs-14 Wietse Venema's TCP wrappers libra ii mysql-client-5.0 [mysql 5.0.45-1 MySQL database client binaries ii python2.4 2.4.4-6 An interactive high-level object-o ii zlib1g 1:1.2.3.3.dfsg-5 compression library - runtime Versions of packages bacula-director-mysql recommends: ii mysql-server-5.0 [mysql-serve 5.0.45-1 MySQL database server binaries
[bacula_passwd.diff (text/plain, attachment)]
Noted your statement that Bug has been forwarded to http://bugs.bacula.org/view.php?id=990.
Request was from John Goerzen <jgoerzen@complete.org>
to control@bugs.debian.org.
(Thu, 18 Oct 2007 16:39:02 GMT) (full text, mbox, link).
Tags added: upstream
Request was from John Goerzen <jgoerzen@complete.org>
to control@bugs.debian.org.
(Thu, 18 Oct 2007 16:39:03 GMT) (full text, mbox, link).
Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#446809; Package bacula-director-mysql.
(full text, mbox, link).
Acknowledgement sent to John Goerzen <jgoerzen@complete.org>:
Extra info received and forwarded to list.
(full text, mbox, link).
Message #14 received at 446809@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Matthijs, What are your thoughts on this?
[forwarded message (message/rfc822, inline)]
From: bacula-bugs@lists.sourceforge.netTo: jgoerzen@complete.orgSubject: [bacula 0000990]: Database password for catalog backups out in the openDate: Fri, 19 Oct 2007 08:29:44 -0400The following issue requires your FEEDBACK. ====================================================================== http://bugs.bacula.org/view.php?id=990 ====================================================================== Reported By: jgoerzen Assigned To: ====================================================================== Project: bacula Issue ID: 990 Category: Director Reproducibility: always Severity: minor Priority: normal Status: feedback ====================================================================== Date Submitted: 10-18-2007 12:25 EDT Last Modified: 10-19-2007 08:29 EDT ====================================================================== Summary: Database password for catalog backups out in the open Description: This report received at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=446809 From: Matthijs Kooijman <matthijs@stdin.nl> Hi, the default bacula configuration file supports backing up the catalog database using the "make_catalog_backup" script. For this, the following line is in bacula-dir.conf: RunBeforeJob = "/etc/bacula/scripts/make_catalog_backup bacula bacula" If the database is password protected, the password must be added as a third argument. This works as expected, but poses up a number of security risks. Firstly, when the backup fails, the complete command line is put into an email with the error messages, including the password. For example: 15-Oct 21:10 stdio.flexvps.nl-dir: BeforeJob: run command "/etc/bacula/scripts/make_catalog_backup bacula bacula c1130ee16f7125579d6214bcd114b71" 15-Oct 21:10 stdio.flexvps.nl-dir: BeforeJob: mysqldump: Got error: 1045: Access denied for user 'bacula'@'localhost' (using password: YES) when trying to +connect Since email is no secure channel, this can expose the database password. Having the database password in the error message hardly serves any purpose and should probably be avoided. Additionally, having the password on the commandline, makes it available to users on the same machine. The command lines of running processes are usually accessible to users, so running a simple matthijs@stdio:~$ ps aux|grep catalog bacula 11706 0.0 0.0 4092 1452 ? S 21:43 0:00 /bin/sh /etc/bacula/scripts/make_catalog_backup bacula bacula 0c1130ee16f7125579d6214bcd114b71 reveals the database password. It would be better to store the password in an external file, and pass that filename to the make_catalog_backup script. In this way, the make_catalog_backup script is still generic, but the database password is not exposed (though that file should be readable by the bacula user, not only by root). The attached patch achieves the above, while maintaining backwards compatibility. It might be better to remove backwards compatibility to prevent users from using the old, insecure way, however. Additionally, my modifications to the script could pose problems if someone uses a database password that is also the name of an existing file. Gr. Matthijs ====================================================================== ---------------------------------------------------------------------- kern - 10-19-07 08:29 ---------------------------------------------------------------------- Yes, I think this is a good idea, but it is a bit too kludgie for me. Instead, what do you think of the idea of having argument 3 be a path to where the password is stored, and it would be in a file named pw-<database-name>. So the my proposed code would test for the existence of the file using: if [ -r "$3/pw-$1" ]; then MYSQLPASSWORD=" --password=`cat \"$3/pw-$1\"`" ... The above would reduce the risk of finding a random file. Probably a simpler proposal would be to ignore argument 3 altogether -- i.e.: if [ -r "pw-$1" ]; then MYSQLPASSWORD=" --password=`cat \"pw-$1\"`" As you mention, the backward compatibility is not very desireable, but not having it would create a *lot* of support problems and possibly some serious errors if the user overlooked fixing it and didn't notice that his catalog backups were failing. Issue History Date Modified Username Field Change ====================================================================== 10-18-07 12:25 jgoerzen New Issue 10-18-07 12:25 jgoerzen File Added: bacula_passwd.diff 10-19-07 08:29 kern Note Added: 0002886 10-19-07 08:29 kern Status new => feedback ======================================================================
Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#446809; Package bacula-director-mysql.
(full text, mbox, link).
Acknowledgement sent to John Goerzen <jgoerzen@complete.org>:
Extra info received and forwarded to list.
(full text, mbox, link).
Message #19 received at 446809@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
[forwarded message (message/rfc822, inline)]
From: bacula-bugs@lists.sourceforge.netTo: jgoerzen@complete.orgSubject: [bacula 0000990]: Database password for catalog backups out in the openDate: Fri, 19 Oct 2007 13:23:39 -0400A NOTE has been added to this issue. ====================================================================== http://bugs.bacula.org/view.php?id=990 ====================================================================== Reported By: jgoerzen Assigned To: ====================================================================== Project: bacula Issue ID: 990 Category: Director Reproducibility: always Severity: minor Priority: normal Status: feedback ====================================================================== Date Submitted: 10-18-2007 12:25 EDT Last Modified: 10-19-2007 13:23 EDT ====================================================================== Summary: Database password for catalog backups out in the open Description: This report received at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=446809 From: Matthijs Kooijman <matthijs@stdin.nl> Hi, the default bacula configuration file supports backing up the catalog database using the "make_catalog_backup" script. For this, the following line is in bacula-dir.conf: RunBeforeJob = "/etc/bacula/scripts/make_catalog_backup bacula bacula" If the database is password protected, the password must be added as a third argument. This works as expected, but poses up a number of security risks. Firstly, when the backup fails, the complete command line is put into an email with the error messages, including the password. For example: 15-Oct 21:10 stdio.flexvps.nl-dir: BeforeJob: run command "/etc/bacula/scripts/make_catalog_backup bacula bacula c1130ee16f7125579d6214bcd114b71" 15-Oct 21:10 stdio.flexvps.nl-dir: BeforeJob: mysqldump: Got error: 1045: Access denied for user 'bacula'@'localhost' (using password: YES) when trying to +connect Since email is no secure channel, this can expose the database password. Having the database password in the error message hardly serves any purpose and should probably be avoided. Additionally, having the password on the commandline, makes it available to users on the same machine. The command lines of running processes are usually accessible to users, so running a simple matthijs@stdio:~$ ps aux|grep catalog bacula 11706 0.0 0.0 4092 1452 ? S 21:43 0:00 /bin/sh /etc/bacula/scripts/make_catalog_backup bacula bacula 0c1130ee16f7125579d6214bcd114b71 reveals the database password. It would be better to store the password in an external file, and pass that filename to the make_catalog_backup script. In this way, the make_catalog_backup script is still generic, but the database password is not exposed (though that file should be readable by the bacula user, not only by root). The attached patch achieves the above, while maintaining backwards compatibility. It might be better to remove backwards compatibility to prevent users from using the old, insecure way, however. Additionally, my modifications to the script could pose problems if someone uses a database password that is also the name of an existing file. Gr. Matthijs ====================================================================== ---------------------------------------------------------------------- kern - 10-19-07 08:29 ---------------------------------------------------------------------- Yes, I think this is a good idea, but it is a bit too kludgie for me. Instead, what do you think of the idea of having argument 3 be a path to where the password is stored, and it would be in a file named pw-<database-name>. So the my proposed code would test for the existence of the file using: if [ -r "$3/pw-$1" ]; then MYSQLPASSWORD=" --password=`cat \"$3/pw-$1\"`" ... The above would reduce the risk of finding a random file. Probably a simpler proposal would be to ignore argument 3 altogether -- i.e.: if [ -r "pw-$1" ]; then MYSQLPASSWORD=" --password=`cat \"pw-$1\"`" As you mention, the backward compatibility is not very desireable, but not having it would create a *lot* of support problems and possibly some serious errors if the user overlooked fixing it and didn't notice that his catalog backups were failing. ---------------------------------------------------------------------- jgoerzen - 10-19-07 10:52 ---------------------------------------------------------------------- Hi Kern, Thanks for your comments on these bugs. I have forwarded your note to Matthijs, who submitted this to DEbian. I'll forward any response back to you. ---------------------------------------------------------------------- COUSINM - 10-19-07 13:23 ---------------------------------------------------------------------- There is be the possibility of using MYSQL_PWD environment variable, just the same as the script does for postgresql. But mysql's documentation says this : Store your password in the MYSQL_PWD environment variable. This method of specifying your MySQL password must be considered extremely insecure and should not be used. Some versions of ps include an option to display the environment of running processes. If you set MYSQL_PWD, your password is exposed to any other user who runs ps. Even on systems without such a version of ps, it is unwise to assume that there are no other methods by which users can examine process environments. See Section 2.4.20, “Environment Variables”. What this paragraph says is applicable for both engines : if the environment variables can be displayed by ps on some systems, it's dangerous. Linux doesn't do that as far as I know, but I don't know for other unixes. The other possibility I see is using configuration files : For mysql, in .my.cnf (in user's home directory) [client] password=your_pass (http://dev.mysql.com/doc/refman/5.0/en/password-security.html) For postgresql, in .pgpass (in user's home directory) hostname:port:database:username:password (http://www.postgresql.org/docs/8.1/interactive/libpq-pgpass.html) With this solution, you get rid of the configuration parameter, but the user has some additionnal setup to do. Issue History Date Modified Username Field Change ====================================================================== 10-18-07 12:25 jgoerzen New Issue 10-18-07 12:25 jgoerzen File Added: bacula_passwd.diff 10-19-07 08:29 kern Note Added: 0002886 10-19-07 08:29 kern Status new => feedback 10-19-07 10:52 jgoerzen Note Added: 0002887 10-19-07 13:23 COUSINM Note Added: 0002888 ======================================================================
Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#446809; Package bacula-director-mysql.
(full text, mbox, link).
Acknowledgement sent to John Goerzen <jgoerzen@complete.org>:
Extra info received and forwarded to list.
(full text, mbox, link).
Message #24 received at 446809@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
[forwarded message (message/rfc822, inline)]
From: bacula-bugs@lists.sourceforge.netTo: jgoerzen@complete.orgSubject: [bacula 0000990]: Database password for catalog backups out in the openDate: Mon, 22 Oct 2007 17:45:13 -0400The following issue has been CLOSED ====================================================================== http://bugs.bacula.org/view.php?id=990 ====================================================================== Reported By: jgoerzen Assigned To: ====================================================================== Project: bacula Issue ID: 990 Category: Director Reproducibility: always Severity: minor Priority: normal Status: closed Resolution: not fixable Fixed in Version: ====================================================================== Date Submitted: 10-18-2007 12:25 EDT Last Modified: 10-22-2007 17:45 EDT ====================================================================== Summary: Database password for catalog backups out in the open Description: This report received at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=446809 From: Matthijs Kooijman <matthijs@stdin.nl> Hi, the default bacula configuration file supports backing up the catalog database using the "make_catalog_backup" script. For this, the following line is in bacula-dir.conf: RunBeforeJob = "/etc/bacula/scripts/make_catalog_backup bacula bacula" If the database is password protected, the password must be added as a third argument. This works as expected, but poses up a number of security risks. Firstly, when the backup fails, the complete command line is put into an email with the error messages, including the password. For example: 15-Oct 21:10 stdio.flexvps.nl-dir: BeforeJob: run command "/etc/bacula/scripts/make_catalog_backup bacula bacula c1130ee16f7125579d6214bcd114b71" 15-Oct 21:10 stdio.flexvps.nl-dir: BeforeJob: mysqldump: Got error: 1045: Access denied for user 'bacula'@'localhost' (using password: YES) when trying to +connect Since email is no secure channel, this can expose the database password. Having the database password in the error message hardly serves any purpose and should probably be avoided. Additionally, having the password on the commandline, makes it available to users on the same machine. The command lines of running processes are usually accessible to users, so running a simple matthijs@stdio:~$ ps aux|grep catalog bacula 11706 0.0 0.0 4092 1452 ? S 21:43 0:00 /bin/sh /etc/bacula/scripts/make_catalog_backup bacula bacula 0c1130ee16f7125579d6214bcd114b71 reveals the database password. It would be better to store the password in an external file, and pass that filename to the make_catalog_backup script. In this way, the make_catalog_backup script is still generic, but the database password is not exposed (though that file should be readable by the bacula user, not only by root). The attached patch achieves the above, while maintaining backwards compatibility. It might be better to remove backwards compatibility to prevent users from using the old, insecure way, however. Additionally, my modifications to the script could pose problems if someone uses a database password that is also the name of an existing file. Gr. Matthijs ====================================================================== ---------------------------------------------------------------------- kern - 10-19-07 08:29 ---------------------------------------------------------------------- Yes, I think this is a good idea, but it is a bit too kludgie for me. Instead, what do you think of the idea of having argument 3 be a path to where the password is stored, and it would be in a file named pw-<database-name>. So the my proposed code would test for the existence of the file using: if [ -r "$3/pw-$1" ]; then MYSQLPASSWORD=" --password=`cat \"$3/pw-$1\"`" ... The above would reduce the risk of finding a random file. Probably a simpler proposal would be to ignore argument 3 altogether -- i.e.: if [ -r "pw-$1" ]; then MYSQLPASSWORD=" --password=`cat \"pw-$1\"`" As you mention, the backward compatibility is not very desireable, but not having it would create a *lot* of support problems and possibly some serious errors if the user overlooked fixing it and didn't notice that his catalog backups were failing. ---------------------------------------------------------------------- jgoerzen - 10-19-07 10:52 ---------------------------------------------------------------------- Hi Kern, Thanks for your comments on these bugs. I have forwarded your note to Matthijs, who submitted this to DEbian. I'll forward any response back to you. ---------------------------------------------------------------------- COUSINM - 10-19-07 13:23 ---------------------------------------------------------------------- There is be the possibility of using MYSQL_PWD environment variable, just the same as the script does for postgresql. But mysql's documentation says this : Store your password in the MYSQL_PWD environment variable. This method of specifying your MySQL password must be considered extremely insecure and should not be used. Some versions of ps include an option to display the environment of running processes. If you set MYSQL_PWD, your password is exposed to any other user who runs ps. Even on systems without such a version of ps, it is unwise to assume that there are no other methods by which users can examine process environments. See Section 2.4.20, “Environment Variables”. What this paragraph says is applicable for both engines : if the environment variables can be displayed by ps on some systems, it's dangerous. Linux doesn't do that as far as I know, but I don't know for other unixes. The other possibility I see is using configuration files : For mysql, in .my.cnf (in user's home directory) [client] password=your_pass (http://dev.mysql.com/doc/refman/5.0/en/password-security.html) For postgresql, in .pgpass (in user's home directory) hostname:port:database:username:password (http://www.postgresql.org/docs/8.1/interactive/libpq-pgpass.html) With this solution, you get rid of the configuration parameter, but the user has some additionnal setup to do. ---------------------------------------------------------------------- Dan Langille - 10-20-07 14:00 ---------------------------------------------------------------------- Perhaps the best course of action is to highlight this as a security issue in the Bacula documentation. Leave it to the user to decide what action to take. Each environment differs. If you are running your database server on a system with non-trusted users, you need to take additional precautions anyway. Document it. Leave it. ---------------------------------------------------------------------- Dan Langille - 10-22-07 13:56 ---------------------------------------------------------------------- See also http://secunia.com/advisories/27243/ ---------------------------------------------------------------------- kern - 10-22-07 17:45 ---------------------------------------------------------------------- I've though about it and decided to go with Dan's suggestion, that is simply to add more documentation to the file indicating that passing the password via the command line is insecure. This is really a database dump implementation problem, or a sys admin problem not really something that Bacula can solve (at least I don't have a solution). In addition, it doesn't seem to me that proposed solution will work, at least not without additional quoting to delay the application of the ` and '. If it does work, it would do so only for MySQL and not for PostgreSQL. In other words, I find it a kludge and not a complete solution. Issue History Date Modified Username Field Change ====================================================================== 10-18-07 12:25 jgoerzen New Issue 10-18-07 12:25 jgoerzen File Added: bacula_passwd.diff 10-19-07 08:29 kern Note Added: 0002886 10-19-07 08:29 kern Status new => feedback 10-19-07 10:52 jgoerzen Note Added: 0002887 10-19-07 13:23 COUSINM Note Added: 0002888 10-20-07 02:34 COUSINM Issue Monitored: COUSINM 10-20-07 14:00 Dan Langille Note Added: 0002891 10-22-07 13:56 Dan Langille Note Added: 0002897 10-22-07 17:45 kern Note Added: 0002898 10-22-07 17:45 kern Status feedback => closed 10-22-07 17:45 kern Resolution open => not fixable ======================================================================
Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#446809; Package bacula-director-mysql.
(full text, mbox, link).
Acknowledgement sent to John Goerzen <jgoerzen@complete.org>:
Extra info received and forwarded to list.
(full text, mbox, link).
Message #29 received at 446809@bugs.debian.org (full text, mbox, reply):
---------- Forwarded Message ----------
Subject: [bacula 0000990]: Database password for catalog backups out in the
open
Date: Monday 22 October 2007
From: bacula-bugs@lists.sourceforge.net
To: jgoerzen@complete.org
A NOTE has been added to this issue.
======================================================================
http://bugs.bacula.org/view.php?id=990
======================================================================
Reported By: jgoerzen
Assigned To:
======================================================================
Project: bacula
Issue ID: 990
Category: Director
Reproducibility: always
Severity: minor
Priority: normal
Status: closed
Resolution: not fixable
Fixed in Version:
======================================================================
Date Submitted: 10-18-2007 12:25 EDT
Last Modified: 10-22-2007 20:32 EDT
======================================================================
Summary: Database password for catalog backups out in the
open
Description:
This report received at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=446809
From: Matthijs Kooijman <matthijs@stdin.nl>
Hi,
the default bacula configuration file supports backing up the catalog
database using the "make_catalog_backup" script. For this, the following
line is in bacula-dir.conf:
RunBeforeJob = "/etc/bacula/scripts/make_catalog_backup bacula bacula"
If the database is password protected, the password must be added as a
third argument. This works as expected, but poses up a number of
security risks.
Firstly, when the backup fails, the complete command line is put into an
email with the error messages, including the password. For example:
15-Oct 21:10 stdio.flexvps.nl-dir: BeforeJob: run command
"/etc/bacula/scripts/make_catalog_backup bacula bacula
c1130ee16f7125579d6214bcd114b71"
15-Oct 21:10 stdio.flexvps.nl-dir: BeforeJob: mysqldump: Got error:
1045: Access denied for user 'bacula'@'localhost' (using password:
YES) when trying to +connect
Since email is no secure channel, this can expose the database password.
Having the database password in the error message hardly serves any
purpose and should probably be avoided.
Additionally, having the password on the commandline, makes it available
to users on the same machine. The command lines of running processes are
usually accessible to users, so running a simple
matthijs@stdio:~$ ps aux|grep catalog
bacula 11706 0.0 0.0 4092 1452 ? S 21:43 0:00 /bin/sh
/etc/bacula/scripts/make_catalog_backup bacula bacula
0c1130ee16f7125579d6214bcd114b71
reveals the database password.
It would be better to store the password in an external file, and pass
that filename to the make_catalog_backup script. In this way, the
make_catalog_backup script is still generic, but the database password
is not exposed (though that file should be readable by the bacula user,
not only by root).
The attached patch achieves the above, while maintaining backwards
compatibility. It might be better to remove backwards compatibility to
prevent users from using the old, insecure way, however. Additionally,
my modifications to the script could pose problems if someone uses a
database password that is also the name of an existing file.
Gr.
Matthijs
======================================================================
----------------------------------------------------------------------
kern - 10-19-07 08:29
----------------------------------------------------------------------
Yes, I think this is a good idea, but it is a bit too kludgie for me.
Instead, what do you think of the idea of having argument 3 be a path to
where the password is stored, and it would be in a file named
pw-<database-name>.
So the my proposed code would test for the existence of the file using:
if [ -r "$3/pw-$1" ]; then
MYSQLPASSWORD=" --password=`cat \"$3/pw-$1\"`"
...
The above would reduce the risk of finding a random file. Probably a
simpler proposal would be to ignore argument 3 altogether -- i.e.:
if [ -r "pw-$1" ]; then
MYSQLPASSWORD=" --password=`cat \"pw-$1\"`"
As you mention, the backward compatibility is not very desireable, but not
having it would create a *lot* of support problems and possibly some
serious errors if the user overlooked fixing it and didn't notice that his
catalog backups were failing.
----------------------------------------------------------------------
jgoerzen - 10-19-07 10:52
----------------------------------------------------------------------
Hi Kern,
Thanks for your comments on these bugs. I have forwarded your note to
Matthijs, who submitted this to DEbian. I'll forward any response back to
you.
----------------------------------------------------------------------
COUSINM - 10-19-07 13:23
----------------------------------------------------------------------
There is be the possibility of using MYSQL_PWD environment variable, just
the same as the script does for postgresql.
But mysql's documentation says this :
Store your password in the MYSQL_PWD environment variable. This method of
specifying your MySQL password must be considered extremely insecure and
should not be used. Some versions of ps include an option to display the
environment of running processes. If you set MYSQL_PWD, your password is
exposed to any other user who runs ps. Even on systems without such a
version of ps, it is unwise to assume that there are no other methods by
which users can examine process environments. See Section 2.4.20,
“Environment Variables”.
What this paragraph says is applicable for both engines : if the
environment variables can be displayed by ps on some systems, it's
dangerous. Linux doesn't do that as far as I know, but I don't know for
other unixes.
The other possibility I see is using configuration files :
For mysql, in .my.cnf (in user's home directory)
[client]
password=your_pass
(http://dev.mysql.com/doc/refman/5.0/en/password-security.html)
For postgresql, in .pgpass (in user's home directory)
hostname:port:database:username:password
(http://www.postgresql.org/docs/8.1/interactive/libpq-pgpass.html)
With this solution, you get rid of the configuration parameter, but the
user has some additionnal setup to do.
----------------------------------------------------------------------
Dan Langille - 10-20-07 14:00
----------------------------------------------------------------------
Perhaps the best course of action is to highlight this as a security issue
in the Bacula documentation. Leave it to the user to decide what action to
take.
Each environment differs. If you are running your database server on a
system with non-trusted users, you need to take additional precautions
anyway.
Document it. Leave it.
----------------------------------------------------------------------
Dan Langille - 10-22-07 13:56
----------------------------------------------------------------------
See also http://secunia.com/advisories/27243/
----------------------------------------------------------------------
kern - 10-22-07 17:45
----------------------------------------------------------------------
I've though about it and decided to go with Dan's suggestion, that is
simply to add more documentation to the file indicating that passing the
password via the command line is insecure.
This is really a database dump implementation problem, or a sys admin
problem not really something that Bacula can solve (at least I don't have a
solution).
In addition, it doesn't seem to me that proposed solution will work, at
least not without additional quoting to delay the application of the ` and
'. If it does work, it would do so only for MySQL and not for PostgreSQL.
In other words, I find it a kludge and not a complete solution.
----------------------------------------------------------------------
Dan Langille - 10-22-07 18:10
----------------------------------------------------------------------
Kern: I'll document the issues on Tuesday. This is something I will enjoy
doing.
----------------------------------------------------------------------
Dan Langille - 10-22-07 19:55
----------------------------------------------------------------------
To date, these are the changes related to this issue:
http://bacula.svn.sourceforge.net/viewvc/bacula?view=rev&revision=5779
http://bacula.svn.sourceforge.net/viewvc/bacula?view=rev&revision=5780
http://bacula.svn.sourceforge.net/viewvc/bacula?view=rev&revision=5782
http://bacula.svn.sourceforge.net/viewvc/bacula?view=rev&revision=5783
----------------------------------------------------------------------
Dan Langille - 10-22-07 20:32
----------------------------------------------------------------------
A few things about this issue which are worth noting. In order for someone
to exploit this issue:
- first, the system would require untrusted users on the database server
- the sysadmin would have to use the default password and database name
(bacula, bacula), unlikely on a server with untrusted users
- if the sysadmin did change the default values, they would have to alter
the invocation of the script, would hopefully raise the issue then
Failing all this, we have added warnings to each place the script is used.
We have also added notes in several places in the documentation. I also
plan to send out an announcement to our users.
Note that in a default installation, the script is invoked with the
default user name and password (bacula, bacula).
Issue History
Date Modified Username Field Change
======================================================================
10-18-07 12:25 jgoerzen New Issue
10-18-07 12:25 jgoerzen File Added: bacula_passwd.diff
10-19-07 08:29 kern Note Added: 0002886
10-19-07 08:29 kern Status new => feedback
10-19-07 10:52 jgoerzen Note Added: 0002887
10-19-07 13:23 COUSINM Note Added: 0002888
10-20-07 02:34 COUSINM Issue Monitored: COUSINM
10-20-07 14:00 Dan Langille Note Added: 0002891
10-22-07 13:56 Dan Langille Note Added: 0002897
10-22-07 17:45 kern Note Added: 0002898
10-22-07 17:45 kern Status feedback => closed
10-22-07 17:45 kern Resolution open => not fixable
10-22-07 18:10 Dan Langille Note Added: 0002899
10-22-07 19:55 Dan Langille Note Added: 0002900
10-22-07 20:32 Dan Langille Note Added: 0002901
======================================================================
-------------------------------------------------------
Information forwarded to debian-bugs-dist@lists.debian.org, John Goerzen <jgoerzen@complete.org>:
Bug#446809; Package bacula-director-mysql.
(full text, mbox, link).
Acknowledgement sent to "Dan Langille" <dan@langille.org>:
Extra info received and forwarded to list. Copy sent to John Goerzen <jgoerzen@complete.org>.
(full text, mbox, link).
Message #37 received at 446809@bugs.debian.org (full text, mbox, reply):
Note: this issue has been documented since 2005: http://www.bacula.org/rel-manual/Bacula_Security_Issues.html "Be aware that if you are backing up your database using the default script, if you have a password on your database, it will be passed as a command line option to that script, and any user will be able to see this information. If you want it to be secure, you will need to pass it by an environment variable or a secure file." Change log: http://bacula.svn.sourceforge.net/viewvc/bacula/trunk/docs/manual/secu rity.tex?view=diff&r1=2701&r2=2702 -- Dan Langille - http://www.langille.org/ Available for hire: http://www.freebsddiary.org/dan_langille.php
Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#446809; Package bacula-director-mysql.
(full text, mbox, link).
Acknowledgement sent to John Goerzen <jgoerzen@complete.org>:
Extra info received and forwarded to list.
(full text, mbox, link).
Message #42 received at 446809@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
[forwarded message (message/rfc822, inline)]
From: bacula-bugs@lists.sourceforge.netTo: jgoerzen@complete.orgSubject: [bacula 0000990]: Database password for catalog backups out in the openDate: Tue, 23 Oct 2007 09:54:28 -0400A NOTE has been added to this issue. ====================================================================== http://bugs.bacula.org/view.php?id=990 ====================================================================== Reported By: jgoerzen Assigned To: ====================================================================== Project: bacula Issue ID: 990 Category: Director Reproducibility: always Severity: minor Priority: normal Status: closed Resolution: not fixable Fixed in Version: ====================================================================== Date Submitted: 10-18-2007 12:25 EDT Last Modified: 10-23-2007 09:54 EDT ====================================================================== Summary: Database password for catalog backups out in the open Description: This report received at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=446809 From: Matthijs Kooijman <matthijs@stdin.nl> Hi, the default bacula configuration file supports backing up the catalog database using the "make_catalog_backup" script. For this, the following line is in bacula-dir.conf: RunBeforeJob = "/etc/bacula/scripts/make_catalog_backup bacula bacula" If the database is password protected, the password must be added as a third argument. This works as expected, but poses up a number of security risks. Firstly, when the backup fails, the complete command line is put into an email with the error messages, including the password. For example: 15-Oct 21:10 stdio.flexvps.nl-dir: BeforeJob: run command "/etc/bacula/scripts/make_catalog_backup bacula bacula c1130ee16f7125579d6214bcd114b71" 15-Oct 21:10 stdio.flexvps.nl-dir: BeforeJob: mysqldump: Got error: 1045: Access denied for user 'bacula'@'localhost' (using password: YES) when trying to +connect Since email is no secure channel, this can expose the database password. Having the database password in the error message hardly serves any purpose and should probably be avoided. Additionally, having the password on the commandline, makes it available to users on the same machine. The command lines of running processes are usually accessible to users, so running a simple matthijs@stdio:~$ ps aux|grep catalog bacula 11706 0.0 0.0 4092 1452 ? S 21:43 0:00 /bin/sh /etc/bacula/scripts/make_catalog_backup bacula bacula 0c1130ee16f7125579d6214bcd114b71 reveals the database password. It would be better to store the password in an external file, and pass that filename to the make_catalog_backup script. In this way, the make_catalog_backup script is still generic, but the database password is not exposed (though that file should be readable by the bacula user, not only by root). The attached patch achieves the above, while maintaining backwards compatibility. It might be better to remove backwards compatibility to prevent users from using the old, insecure way, however. Additionally, my modifications to the script could pose problems if someone uses a database password that is also the name of an existing file. Gr. Matthijs ====================================================================== ---------------------------------------------------------------------- kern - 10-19-07 08:29 ---------------------------------------------------------------------- Yes, I think this is a good idea, but it is a bit too kludgie for me. Instead, what do you think of the idea of having argument 3 be a path to where the password is stored, and it would be in a file named pw-<database-name>. So the my proposed code would test for the existence of the file using: if [ -r "$3/pw-$1" ]; then MYSQLPASSWORD=" --password=`cat \"$3/pw-$1\"`" ... The above would reduce the risk of finding a random file. Probably a simpler proposal would be to ignore argument 3 altogether -- i.e.: if [ -r "pw-$1" ]; then MYSQLPASSWORD=" --password=`cat \"pw-$1\"`" As you mention, the backward compatibility is not very desireable, but not having it would create a *lot* of support problems and possibly some serious errors if the user overlooked fixing it and didn't notice that his catalog backups were failing. ---------------------------------------------------------------------- jgoerzen - 10-19-07 10:52 ---------------------------------------------------------------------- Hi Kern, Thanks for your comments on these bugs. I have forwarded your note to Matthijs, who submitted this to DEbian. I'll forward any response back to you. ---------------------------------------------------------------------- COUSINM - 10-19-07 13:23 ---------------------------------------------------------------------- There is be the possibility of using MYSQL_PWD environment variable, just the same as the script does for postgresql. But mysql's documentation says this : Store your password in the MYSQL_PWD environment variable. This method of specifying your MySQL password must be considered extremely insecure and should not be used. Some versions of ps include an option to display the environment of running processes. If you set MYSQL_PWD, your password is exposed to any other user who runs ps. Even on systems without such a version of ps, it is unwise to assume that there are no other methods by which users can examine process environments. See Section 2.4.20, “Environment Variables”. What this paragraph says is applicable for both engines : if the environment variables can be displayed by ps on some systems, it's dangerous. Linux doesn't do that as far as I know, but I don't know for other unixes. The other possibility I see is using configuration files : For mysql, in .my.cnf (in user's home directory) [client] password=your_pass (http://dev.mysql.com/doc/refman/5.0/en/password-security.html) For postgresql, in .pgpass (in user's home directory) hostname:port:database:username:password (http://www.postgresql.org/docs/8.1/interactive/libpq-pgpass.html) With this solution, you get rid of the configuration parameter, but the user has some additionnal setup to do. ---------------------------------------------------------------------- Dan Langille - 10-20-07 14:00 ---------------------------------------------------------------------- Perhaps the best course of action is to highlight this as a security issue in the Bacula documentation. Leave it to the user to decide what action to take. Each environment differs. If you are running your database server on a system with non-trusted users, you need to take additional precautions anyway. Document it. Leave it. ---------------------------------------------------------------------- Dan Langille - 10-22-07 13:56 ---------------------------------------------------------------------- See also http://secunia.com/advisories/27243/ ---------------------------------------------------------------------- kern - 10-22-07 17:45 ---------------------------------------------------------------------- I've though about it and decided to go with Dan's suggestion, that is simply to add more documentation to the file indicating that passing the password via the command line is insecure. This is really a database dump implementation problem, or a sys admin problem not really something that Bacula can solve (at least I don't have a solution). In addition, it doesn't seem to me that proposed solution will work, at least not without additional quoting to delay the application of the ` and '. If it does work, it would do so only for MySQL and not for PostgreSQL. In other words, I find it a kludge and not a complete solution. ---------------------------------------------------------------------- Dan Langille - 10-22-07 18:10 ---------------------------------------------------------------------- Kern: I'll document the issues on Tuesday. This is something I will enjoy doing. ---------------------------------------------------------------------- Dan Langille - 10-22-07 19:55 ---------------------------------------------------------------------- To date, these are the changes related to this issue: http://bacula.svn.sourceforge.net/viewvc/bacula?view=rev&revision=5779 http://bacula.svn.sourceforge.net/viewvc/bacula?view=rev&revision=5780 http://bacula.svn.sourceforge.net/viewvc/bacula?view=rev&revision=5782 http://bacula.svn.sourceforge.net/viewvc/bacula?view=rev&revision=5783 ---------------------------------------------------------------------- Dan Langille - 10-22-07 20:32 ---------------------------------------------------------------------- A few things about this issue which are worth noting. In order for someone to exploit this issue: - first, the system would require untrusted users on the database server - the sysadmin would have to use the default password and database name (bacula, bacula), unlikely on a server with untrusted users - if the sysadmin did change the default values, they would have to alter the invocation of the script, would hopefully raise the issue then Failing all this, we have added warnings to each place the script is used. We have also added notes in several places in the documentation. I also plan to send out an announcement to our users. Note that in a default installation, the script is invoked with the default user name and password (bacula, bacula). ---------------------------------------------------------------------- Dan Langille - 10-23-07 09:54 ---------------------------------------------------------------------- Note: this issue has been documented since 2005: http://www.bacula.org/rel-manual/Bacula_Security_Issues.html "Be aware that if you are backing up your database using the default script, if you have a password on your database, it will be passed as a command line option to that script, and any user will be able to see this information. If you want it to be secure, you will need to pass it by an environment variable or a secure file." Change log: http://bacula.svn.sourceforge.net/viewvc/bacula/trunk/docs/manual/security.tex?view=diff&r1=2701&r2=2702 Issue History Date Modified Username Field Change ====================================================================== 10-18-07 12:25 jgoerzen New Issue 10-18-07 12:25 jgoerzen File Added: bacula_passwd.diff 10-19-07 08:29 kern Note Added: 0002886 10-19-07 08:29 kern Status new => feedback 10-19-07 10:52 jgoerzen Note Added: 0002887 10-19-07 13:23 COUSINM Note Added: 0002888 10-20-07 02:34 COUSINM Issue Monitored: COUSINM 10-20-07 14:00 Dan Langille Note Added: 0002891 10-22-07 13:56 Dan Langille Note Added: 0002897 10-22-07 17:45 kern Note Added: 0002898 10-22-07 17:45 kern Status feedback => closed 10-22-07 17:45 kern Resolution open => not fixable 10-22-07 18:10 Dan Langille Note Added: 0002899 10-22-07 19:55 Dan Langille Note Added: 0002900 10-22-07 20:32 Dan Langille Note Added: 0002901 10-23-07 09:54 Dan Langille Note Added: 0002903 ======================================================================
Information forwarded to debian-bugs-dist@lists.debian.org, John Goerzen <jgoerzen@complete.org>:
Bug#446809; Package bacula-director-mysql.
(full text, mbox, link).
Acknowledgement sent to Nico Golde <nion@debian.org>:
Extra info received and forwarded to list. Copy sent to John Goerzen <jgoerzen@complete.org>.
(full text, mbox, link).
Message #47 received at 446809@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
retitle 446809 CVE-2007-5626 unauthorized disclosure of information via clear-text passwords used in command line arguments thanks Hi, CVE-2007-5626 has been assigned to this. Kind regards Nico -- Nico Golde - http://www.ngolde.de - nion@jabber.ccc.de - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted.
[Message part 2 (application/pgp-signature, inline)]
Changed Bug title to `CVE-2007-5626 unauthorized disclosure of information via clear-text passwords used in command line arguments' from `bacula-director-mysql: Database password for catalog backups out in the open'.
Request was from Nico Golde <nion@debian.org>
to control@bugs.debian.org.
(Sun, 28 Oct 2007 16:09:03 GMT) (full text, mbox, link).
Information forwarded to debian-bugs-dist@lists.debian.org, John Goerzen <jgoerzen@complete.org>:
Bug#446809; Package bacula-director-mysql.
(full text, mbox, link).
Acknowledgement sent to Kern Sibbald <kern@sibbald.com>:
Extra info received and forwarded to list. Copy sent to John Goerzen <jgoerzen@complete.org>.
(full text, mbox, link).
Message #54 received at 446809@bugs.debian.org (full text, mbox, reply):
There is no simple solution that works in all cases that I am aware of. This potential security problem (no worse than configuring your conf file with world read permission) has been documented for quite a long time in the manual. We've added additional documentation to the scripts in question warning the user of security problems. No other changes planned.
Reply sent to John Goerzen <jgoerzen@complete.org>:
You have taken responsibility.
(full text, mbox, link).
Notification sent to Matthijs Kooijman <matthijs@stdin.nl>:
Bug acknowledged by developer.
(full text, mbox, link).
Message #59 received at 446809-done@bugs.debian.org (full text, mbox, reply):
See Kern's comment at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=446809 Full details at http://bugs.bacula.org/view.php?id=990 These changes are already in Debian
Bug archived.
Request was from Debbugs Internal Request <owner@bugs.debian.org>
to internal_control@bugs.debian.org.
(Wed, 27 Feb 2008 07:26:53 GMT) (full text, mbox, link).
Send a report that this bug log contains spam.
Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.
Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors.