Debian Bug report logs - #446809
CVE-2007-5626 unauthorized disclosure of information via clear-text passwords used in command line arguments

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.

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

Toggle useless messages

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 and rfc822 format available.

Acknowledgement sent to Matthijs Kooijman <matthijs@stdin.nl>:
New Bug report received and forwarded. Copy sent to John Goerzen <jgoerzen@complete.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

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
[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 and rfc822 format available.

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 and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#446809; Package bacula-director-mysql. Full text and rfc822 format available.

Acknowledgement sent to John Goerzen <jgoerzen@complete.org>:
Extra info received and forwarded to list. Full text and rfc822 format available.

Message #14 received at 446809@bugs.debian.org (full text, mbox):

From: John Goerzen <jgoerzen@complete.org>
To: matthijs@stdin.nl
Cc: 446809@bugs.debian.org
Subject: Fwd: [bacula 0000990]: Database password for catalog backups out in the open
Date: Fri, 19 Oct 2007 09:52:00 -0500
[Message part 1 (text/plain, inline)]
Matthijs,

What are your thoughts on this?
[forwarded message (message/rfc822, inline)]
From: bacula-bugs@lists.sourceforge.net
To: jgoerzen@complete.org
Subject: [bacula 0000990]: Database password for catalog backups out in the open
Date: Fri, 19 Oct 2007 08:29:44 -0400
The 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 and rfc822 format available.

Acknowledgement sent to John Goerzen <jgoerzen@complete.org>:
Extra info received and forwarded to list. Full text and rfc822 format available.

Message #19 received at 446809@bugs.debian.org (full text, mbox):

From: John Goerzen <jgoerzen@complete.org>
To: 446809@bugs.debian.org
Subject: Fwd: [bacula 0000990]: Database password for catalog backups out in the open
Date: Fri, 19 Oct 2007 12:49:29 -0500
[Message part 1 (text/plain, inline)]

[forwarded message (message/rfc822, inline)]
From: bacula-bugs@lists.sourceforge.net
To: jgoerzen@complete.org
Subject: [bacula 0000990]: Database password for catalog backups out in the open
Date: Fri, 19 Oct 2007 13:23:39 -0400
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:                     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 and rfc822 format available.

Acknowledgement sent to John Goerzen <jgoerzen@complete.org>:
Extra info received and forwarded to list. Full text and rfc822 format available.

Message #24 received at 446809@bugs.debian.org (full text, mbox):

From: John Goerzen <jgoerzen@complete.org>
To: 446809@bugs.debian.org
Subject: Fwd: [bacula 0000990]: Database password for catalog backups out in the open
Date: Mon, 22 Oct 2007 16:49:20 -0500
[Message part 1 (text/plain, inline)]

[forwarded message (message/rfc822, inline)]
From: bacula-bugs@lists.sourceforge.net
To: jgoerzen@complete.org
Subject: [bacula 0000990]: Database password for catalog backups out in the open
Date: Mon, 22 Oct 2007 17:45:13 -0400
The 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 and rfc822 format available.

Acknowledgement sent to John Goerzen <jgoerzen@complete.org>:
Extra info received and forwarded to list. Full text and rfc822 format available.

Message #29 received at 446809@bugs.debian.org (full text, mbox):

From: John Goerzen <jgoerzen@complete.org>
To: 446809@bugs.debian.org, 446809-submitter@bugs.debian.org
Subject: Fwd: [bacula 0000990]: Database password for catalog backups out in the open
Date: Tue, 23 Oct 2007 01:58:27 -0500
----------  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                          
======================================================================



-------------------------------------------------------




Message sent on to Matthijs Kooijman <matthijs@stdin.nl>:
Bug#446809. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, John Goerzen <jgoerzen@complete.org>:
Bug#446809; Package bacula-director-mysql. Full text and rfc822 format available.

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 and rfc822 format available.

Message #37 received at 446809@bugs.debian.org (full text, mbox):

From: "Dan Langille" <dan@langille.org>
To: 446809@bugs.debian.org
Subject: isse documented in 2005
Date: Tue, 23 Oct 2007 11:11:48 -0400
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 and rfc822 format available.

Acknowledgement sent to John Goerzen <jgoerzen@complete.org>:
Extra info received and forwarded to list. Full text and rfc822 format available.

Message #42 received at 446809@bugs.debian.org (full text, mbox):

From: John Goerzen <jgoerzen@complete.org>
To: 446809@bugs.debian.org
Subject: Fwd: [bacula 0000990]: Database password for catalog backups out in the open
Date: Tue, 23 Oct 2007 20:28:41 -0500
[Message part 1 (text/plain, inline)]

[forwarded message (message/rfc822, inline)]
From: bacula-bugs@lists.sourceforge.net
To: jgoerzen@complete.org
Subject: [bacula 0000990]: Database password for catalog backups out in the open
Date: Tue, 23 Oct 2007 09:54:28 -0400
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-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 and rfc822 format available.

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 and rfc822 format available.

Message #47 received at 446809@bugs.debian.org (full text, mbox):

From: Nico Golde <nion@debian.org>
To: 446809@bugs.debian.org
Cc: control@bugs.debian.org
Subject: Re: bacula-director-mysql: Database password for catalog backups out in the open
Date: Sun, 28 Oct 2007 17:08:18 +0100
[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 and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, John Goerzen <jgoerzen@complete.org>:
Bug#446809; Package bacula-director-mysql. Full text and rfc822 format available.

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 and rfc822 format available.

Message #54 received at 446809@bugs.debian.org (full text, mbox):

From: Kern Sibbald <kern@sibbald.com>
To: 446809@bugs.debian.org
Subject: Debian Bug report logs - #446809 CVE-2007-5626 unauthorized disclosure of information via clear-text passwords used in command line arguments
Date: Mon, 5 Nov 2007 23:25:09 +0100
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 and rfc822 format available.

Notification sent to Matthijs Kooijman <matthijs@stdin.nl>:
Bug acknowledged by developer. Full text and rfc822 format available.

Message #59 received at 446809-done@bugs.debian.org (full text, mbox):

From: John Goerzen <jgoerzen@complete.org>
To: 446809-done@bugs.debian.org
Subject: Closing this
Date: Tue, 29 Jan 2008 09:20:36 -0600
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 and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 17 19:10:52 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.