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.
