Bugzilla Bug 196834

CVE-2007-5626 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-5626):
  make_catalog_backup in Bacula 2.2.5, and probably earlier, sends a MySQL
  password as a command line argument, and sometimes transmits cleartext e-mail
  containing this command line, which allows context-dependent attackers to
  obtain the password by listing the process and its arguments, or by sniffing
  the network.

From http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=446809:

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."
...

Backup, Wolfram - please advise.

Nobody should use that dumb script :)

I am using this Job myself to backup the catalog:
--8<--
# Backup the catalog database (after the nightly save)
Job {
        Enabled = yes
        Name = "BackupCatalog"
        Type = Backup
        Client = prometheus-fd
        Level = Full
        FileSet = "Catalog"
        Storage = "File"
        Pool = "DefaultPool"
        Schedule = "WeeklyCycleAfterBackup"
        Messages = Standard
        RunBeforeJob = "mysqldump --defaults-file=/etc/bacula/my.cnf --opt -f
-r /var/lib/bacula/bacula.sql bacula"
        RunAfterJob  = "rm -f /var/lib/bacula/bacula.sql"
        Write Bootstrap = "/var/lib/bacula/BackupCatalog.bsr"
        Priority = 11 # run after backups which have a priority of 10
}
--8<--
As you can see from the RunBeforeJob, the mysqldump is using
the custom defaults file /etc/bacula/my.cnf which contains
the relevant authentication data.
Maybe we should advise the users from pkg_postinst() to do
it that way...
It's not difficult to write a custom catalog backup wrapper
script that takes care of secure password handling IMHO.

(In reply to comment #3)
> It's not difficult to write a custom catalog backup wrapper
> script that takes care of secure password handling IMHO.

Is it possible not to install that file? The problem is that if a packages
installs it, users might trust it. If you have a good script, why not include
that one? Also, the debian bug referenced above has a patch for the script.

Either of the three options sounds better than blindly installing that script.

Any news here? Wolfram, what do you suggest?

(In reply to comment #5)
> Any news here? Wolfram, what do you suggest?
> 

*ping*

what is the status on this one???

(In reply to comment #4)
> (In reply to comment #3)
> > It's not difficult to write a custom catalog backup wrapper
> > script that takes care of secure password handling IMHO.
> 
> Is it possible not to install that file? The problem is that if a packages
> installs it, users might trust it. If you have a good script, why not include
> that one? Also, the debian bug referenced above has a patch for the script.
> 
> Either of the three options sounds better than blindly installing that script.

Well, the bundled script works for several database types
(mysql, pgsql, sqlite) whereas what I posted only works
for mysql.

Personally I do not want to skip installing that file (I'd
have to patch the default configs as well).
I consider that script as an _example_, nothing more (yes,
I know that it's "enabled" by default).
If a user *wants* to use that script without modification,
it's his decision.

I'd like to warn the user from pkg_postinst() instead.
Anyone blindly using such complex applications is
simply wrong IMHO.

 > I'd like to warn the user from pkg_postinst() instead.
> Anyone blindly using such complex applications is
> simply wrong IMHO.
> 

Sounds like an acceptable solution. could you please provide an updated ebuild?

(In reply to comment #9)
>  > I'd like to warn the user from pkg_postinst() instead.
> > Anyone blindly using such complex applications is
> > simply wrong IMHO.
> 
> Sounds like an acceptable solution. could you please provide an updated ebuild?

I just added this to 2.4.0-r1 (which I did not commit yet) -- what do
you think?

 * *** ATTENTION! IMPORTANT! ATTENTION! IMPORTANT! ATTENTION! IMPORTANT! ***
 *
 * The bundled catalog backup script (/usr/libexec/bacula/make_catalog_backup)
 * is INSECURE. The script needs to be called with the database access password
 * as a command line parameter, thus, the password can be seen from any other
 * user on the system (if not using some non-default hardened/patched kernel
 * with /proc restrictions)!
 *
 * Our advice is to NOT USE the bundled script at all, but instead use
something
 * like this in your catalog backup job definition (example using MySQL as the
 * catalog database):
 *
 * RunBeforeJob = "mysqldump --defaults-file=/etc/bacula/my.cnf --opt -f -r
/var/lib/bacula/bacula.sql bacula"
 * RunAfterJob  = "rm -f /var/lib/bacula/bacula.sql"
 *
 * This requires you to put all database access parameters (like user, host and
 * password) into a dedicated file (/etc/bacula/my.cnf in this example) which
 * can (and should!) be secured by simple filesystem access permissions.
 *
 * *** ATTENTION! IMPORTANT! ATTENTION! IMPORTANT! ATTENTION! IMPORTANT! ***

looks ok to me. security, any opinions? 
wolfram: if no one objects in the next few days, I think you can commit it.

I'm about to commit 2.4.1 which has that security warning...

Committed 2.4.1 incorporating the warning.

thanks.
Arches, please test and mark stable app-backup/bacula-2.4.1. Target KEYWORDS:
"~amd64 hppa ppc sparc x86"

Sparc stable, everything as expected. Active USE flags for this build:
X bacula-console doc mysql python qt4 readline ssl tcpd

ppc stable

Stable for HPPA.

Any reason you missed amd64 here?

x86 stable

(In reply to comment #18)
> Any reason you missed amd64 here?
> 

Yep, AFAICT there were no previous stable version. if you want it stable on
amd64, you'll have to open a new bug. All arches done, time for GLSA decision.
I vote YES.

YES for sure, filing request.

GLSA 200807-10, sorry for the delay.

I assume this effects postgresql as well.