#2155 Issue `closed`: User's secret BACKUP_PROG_CRYPT_KEY value is shown in backup.log¶

Labels: fixed / solved / done, critical / security / legal

chumunga opened issue at 2019-06-05 19:41:¶

Relax-and-Recover (ReaR) Issue Template¶

Fill in the following items before submitting a new issue
(quick response is not guaranteed with free support):

ReaR version ("/usr/sbin/rear -V"):

rear -Dv mkbackup
Relax-and-Recover 2.4 / Git
Using log file: /var/log/rear/rear-mobilitysrv.log
Using backup archive '/tmp/rear.FkQ7wN7hLVsm2jI/outputfs/mobilitysrv/backup.tar.gz'
Creating disk layout
Using guessed bootloader 'GRUB' (found in first bytes on /dev/sda)
Creating root filesystem layout
Handling network interface 'em1'
em1 is a physical device
Handled network interface 'em1'
Skipping 'virbr0': not bound to any physical interface.
Copying logfile /var/log/rear/rear-mobilitysrv.log into initramfs as '/tmp/rear-mobilitysrv-partial-2019-06-05T12:18:21-0700.log'
Copying files and directories
Copying binaries and libraries
Copying kernel modules
Copying all files in /lib*/firmware/
Removing all encryption Keys from initrd
Creating recovery/rescue system initramfs/initrd initrd.cgz with gzip default compression
Created initrd.cgz with gzip default compression (200405161 bytes) in 24 seconds
Making ISO image
Wrote ISO image: /var/lib/rear/output/rear-mobilitysrv.iso (200M)
Copying resulting files to cifs location
Saving /var/log/rear/rear-mobilitysrv.log as rear-mobilitysrv.log to cifs location
Encrypting backup archive with key defined in variable $BACKUP_PROG_CRYPT_KEY
Creating tar archive '/tmp/rear.FkQ7wN7hLVsm2jI/outputfs/mobilitysrv/backup.tar.gz'
Preparing archive operationOK
Exiting rear mkbackup (PID 15729) and its descendant processes
Running exit tasks
You should also rm -Rf /tmp/rear.FkQ7wN7hLVsm2jI
[root@mobilitysrv ~]#

OS version ("cat /etc/rear/os.conf" or "lsb_release -a" or "cat /etc/os-release"):

OS_VENDOR=RedHatEnterpriseServer
OS_VERSION=7

ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):

OUTPUT=ISO
BACKUP=NETFS
BACKUP_PROG=tar
#BACKUP_TYPE=incremental
#FULLBACKUPDAY="Mon"
#FULLBACKUP_OUTDATED_DAYS=5
BACKUP_PROG_CRYPT_ENABLED=1
BACKUP_PROG_CRYPT_KEY=U@eQ6?FJy
BACKUP_PROG_CRYPT_OPTIONS="/usr/bin/openssl aes-256-cbc -salt -k"
BACKUP_PROG_DECRYPT_OPTIONS="/usr/bin/openssl aes-256-cbc -d -k"
BACKUP_URL=cifs://192.168.0.95/corp_server/mobilitysrv
BACKUP_OPTIONS="cred=/root/.confid/.cifs,vers=1.0"

Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR):
PC
System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
x86
Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
BIOS, GRUB
Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
NAS
Description of the issue (ideally so that others can reproduce it):

When running rear -v mkbackup, at the point "Creating tar archive '/tmp..."
I would bee Archived and a counter showing how much has been archived.
From my output above, this Archiving status never shows in terminal and
the backup.tar output file is 0 Bytes, and I don't see any obvious error files in the log.

Also in the log file I see that BACKUP_PROG_CRYPT_KEY=
which is baffling since my other Rear test, the password is never present in the log.

the way I installed rear was:
yum install rear

Workaround, if any:
Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):

chumunga commented at 2019-06-05 20:20:¶

I think I may have inadvertently solved this by running yum update, but I had to run yum remove rear, then yum install rear and now its backing up.

I will report back if the log file has the password.

jsmeix commented at 2019-06-06 07:10:¶

@chumunga
how exactly is the log entry with BACKUP_PROG_CRYPT_KEY=... ?
My offhanded guess is that it looks like

+ source /root/rear.github.master/etc/rear/local.conf
...
++ BACKUP_PROG_CRYPT_KEY=my_secret_key

i.e. with leading '+' but never without leading '+'
which means you only get it in debugscript mode with -D
(see "man rear" what debugscript mode does)
and then it works as designed.

But - what is worse - the BACKUP_PROG_CRYPT_KEY value my_secret_key
gets explicitly logged to the separated backup.log file (when not in debugscript mode)
for example in usr/share/rear/restore/NETFS/default/400_restore_backup.sh
by this code

    Log ...
        ... $BACKUP_PROG_DECRYPT_OPTIONS $BACKUP_PROG_CRYPT_KEY ...

This are the files that contain BACKUP_PROG_CRYPT_KEY

# find usr/sbin/rear usr/share/rear/ -type f | xargs grep -l 'BACKUP_PROG_CRYPT_KEY'
usr/share/rear/build/default/960_remove_encryption_keys.sh
usr/share/rear/restore/NETFS/default/400_restore_backup.sh
usr/share/rear/restore/YUM/default/405_recreate_users_and_groups.sh
usr/share/rear/restore/YUM/default/410_restore_backup.sh
usr/share/rear/backup/NETFS/default/500_make_backup.sh
usr/share/rear/conf/default.conf
usr/share/rear/verify/NETFS/default/600_check_encryption_key.sh

I will check them all...

@chumunga
thank you very much for your careful inspection of what is in the log.
It is a critical security issue when secrets appear in a log file
(unless rear is run in debugscript mode).

jsmeix commented at 2019-06-06 08:43:¶

chumunga commented at 2019-06-06 17:17:¶

Ahh sorry your right I did use the -D since I was testing/debugging.

Also I resolved the issue of the backup file zero byte issue. I believe my mistake was that I ran
#yum install rear syslinux genisoimage cifs-utils grub2-efi-x64-modules
First, then ran yum update (there was a lot to update) and this is when I had the issue.

However, I then decided to run Yum remove rear, then followed by yum install rear and this resolved the issue for me.

jsmeix commented at 2019-06-07 13:16:¶

With https://github.com/rear/rear/pull/2156 merged the issue described
in https://github.com/rear/rear/issues/2155#issuecomment-499376750
should be fixed.

[Export of Github issue for rear/rear.]

#2155 Issue closed: User's secret BACKUP_PROG_CRYPT_KEY value is shown in backup.log¶