Bugzilla – Bug 1182918
VUL-0: CVE-2021-25319: virtualbox: missing sticky bit for /etc/vbox allows local root exploit for members of vboxusers group
Last modified: 2021-10-09 08:00:45 UTC
+++ This bug was initially created as a clone of Bug #1180879 The security team is currently inspecting scripts and code checked into OBS directly in openSUSE:Factory packages. As part of this I looked into the virtualbox package which has the following script files checked in: - fix_usb_rules.sh - update-extpack.sh - vboxautostart.sh - vboxconfig.sh - vboxdrv.sh - vboxweb-service.sh - virtualbox-patch-source.sh - virtualbox-wrapper.sh Most of these scripts seem to have been extracted from the RPM distributions provided by www.virtualbox.org. The "autostart" mechanism uses a "database" directory in /etc/vbox. There exist instructions on the Internet to set this directory up as a sticky bit directory owned by root:vboxusers mode 1775, for example in [1]. [1]: https://kifarunix.com/autostart-virtualbox-vms-on-system-boot-on-linux The script vboxautostart.sh, vboxdrv.sh and vboxweb-service.sh all run as root and source /etc/vbox/vbox.cfg. In our openSUSE packaging bad permissions are used for /etc/vbox at least since OBS sr#662944, which, ironically, says "proper permissions for /etc/vbox/*.cfg". However the following lines in the %files section of the spec file cause trouble: ``` %dir %{_sysconfdir}/vbox %attr(1775,root,vboxusers) %{_sysconfdir}/vbox ``` The follow-up `%attr` line is not effective, causing the sticky bit to be missing during installation. The directory is stilled group-writable by the vboxusers group though. This means that any member of the vboxusers group can replace the /etc/vbox/vbox.cfg file by a manipulated once, allowing for full code execution in the context of the root user once e.g. the vboxautostart systemd service runs. Reproducer: ``` root# su -g vboxusers nobody nobody$ cd /etc/vbox nobody$ cp vbox.cfg vbox.cfg.new nobody$ rm -f vbox.cfg nobody$ mv vbox.cfg.new vbox.cfg nobody$ echo "touch /root/evil" >>vbox.cfg nobody$ exit root# systemctl start vboxautostart.service root# ls -lh /root/evil -rw-r--r-- 1 root root 0 2. Mär 12:14 /root/evil ``` I have been looking into other distributions like Arch Linux, Fedora and also some of the RPMs distributed on www.virtualbox.org. It seems they all package /etc/vbox as root:root mode 755. This local root exploit therefore seems to be openSUSE specific and we will need to assign a SUSE CVE for this issue. We can handle fixing and publication of this issue ourselves. virtualbox is not in any enterprise versions of SUSE it seems. But all of openSUSE:Leap:15.{1,2,3} is also affected and needs to be fixed. If you are aware of any other distribution that has the packaging error then please tell us so we can give them a heads up.
I also want to bring to your attention that the "correct" setup of /etc/vbox with sticky bit set i.e. mode 1775 and ownership root:vboxusers is still not robust, security wise. When looking at the script vboxautostart.sh we find the following logic for autostarting VM ``` IFS=$'\n' [...] if [ -r $VBOXAUTOSTART_CONFIG ]; then [...] # find all the files of type username.start var=$(ls $VBOXAUTOSTART_DB | grep start | grep -v auto) # process each file of that type for i in $var; do # Extract the user name - the first word on the line user=$(echo $i | head -n1 | cut -d "." -f1) # autostart the VMs for that user begin_msg "Starting VMs for user $user" console su - $user -c "/usr/lib/virtualbox/VBoxAutostart --start --config $VBOXAUTOSTART_CONFIG" succ_msg "VMs for user $user started" done fi IFS=$OLD_IFS ``` VBOXAUTOSTART_DB is set to /etc/vbox in /etc/default/virtualbox. Even with the sticky bit set on /etc/vbox, any member of the vboxusers group can create arbitrary new files in this directory. This means due to the line user=$(echo $i | head -n1 | cut -d "." -f1) any member of the vboxusers group can manipulate the value of this user variable. This user variable is then passed to `su` as second argument: su - $user -c "/usr/lib/virtualbox/VBoxAutostart --start --config $VBOXAUTOSTART_CONFIG" Example reproducer: ``` root# su -g vboxusers nobody nobody$ cd /etc/vbox nobody$ touch -- '-s myshell.start' nobody$ exit root# /usr/lib/virtualbox/vboxautostart.sh start vboxautostart.sh: Starting VirtualBox VMs configured for autostart. vboxautostart.sh: Starting VMs for user -s myshell. su: failed to execute myshell: No such file or directory ``` Luckily this is not a full local root exploit. Two aspects are reponsible for this: - filenames cannot contain slash '/' characters, therefore we cannot specify any valid executable beyond the CWD of the autosart.sh script. - the $user argument is passed before the `-c /usr/lib/virtualbox/VBoxAutostart` parameter. And the command line parsing logic of su lets the final `-c` parameter "win", i.e. the attacker cannot influence the command that is run. Still a local attacker can specify arbitrary other parameters to `su` this way e.g. the `--group=mygroup` parameter. It could be a successful attack vector when combined with other security issues. Beyond this any member of the vboxusers group can influence the autostart setting of other users, as long as the victim user is allowed to autostart via /etc/vbox/autostart.cfg. On a more generic level the design of /etc/vbox with sticky bit set allows any member of the vboxusers group to trigger a run of /usr/lib/virtualbox/VBoxAutostart as any local user (by influencing the $user value) or as root with any local group (by setting $user to --group=mygroup). Given all this I don't recommend granting write access to /etc/vbox to the vboxusers group. Please package it as root:root mode 755. This robustness issue with the sticky bit involved might be something that we need to report to Oracle upstream or whoever is responsible for this whole idea of a /etc/vbox sticky bit directory writeable by the vboxusers group.
I changed the ownership of /etc/vbox to root:root with mode 755. After that, VBoxManage was unable to set autostart on. It failed with an access violation. I then installed the latest test version of VirtualBox from Oracle. It has the same problem. Only when I set the ownership to root:vboxusers with mode 775 can I set autostart on. At present, there does not appear to be a workaround. I looked into modifying VBoxManage to see what modifications I might make, but I am not a C++ programmer, and I quickly get lost in the code that manages autostart. I can get it to work if I change the autostartdb from /etc/vbox to /etc/vbox/autostart.d/, ownership of /etc/vbox to root:root, and the mode to 755. The ownership of autostart.d is root:vboxusers with mode 1755. I'm not sure that this helps the security.
Created attachment 847970 [details] Patches for autostart Attached is a set of patches that should make autostart as secure as possible within the current structure. These have the following effects: 1. VBOXAUTOSTART_DB is changed from /etc/vbox to /etc/vbox/autostart.d 2. /etc/vbox is now owned by root:root with mode 0755 3. /etc/vbox/autostart.d is owned by root:vboxusers with mode 1775 This setup makes it so that /etc/vbox/autostart.cfg can only be changed by root, but files /etc/vbox/autostart.d/<username>.start can be created or deleted by any user. Although users can create other files in autostart.d, nothing will ever reference files other than *.start. Does this satisfy the BUG?
The patch in attachment 847970 [details] should fix the full local root exploit as described in comment 0. It still will be susceptible to the problems described in comment 2, though. Since the Factory package is currently broken as it seems you can try to go with the current patch to fix the situation and then lets go on from there. Please let me have a look at the package before you submit it to Factory. To fix the aspect described in comment 2 we might need to patch the vboxautostart.sh script, too. I can help you with that if you like.
The updated coode is at: https://build.opensuse.org/package/rdiff/home:lwfinger:branches:Virtualization/virtualbox?linkrev=base&rev=2 Changes are as follows: /etx/vbox now owned by root:root mode 755 VBOXAUTOSTART_DB is now set to /etc/vbox/autostart.d. That directory is owned by root:vboxusers mode 1770. I see no reason for that directory to be executable, but it fails unless those permissions are used. I gave it a minimal change description as I was not sure how much to disclose about the vulnerability.
Created attachment 848123 [details] hardening for vboxautostart.sh
To fix the issue described in comment 2 please integrate my suggested patch in attachment 848123 [details].
Regarding the patch and comment 13, please wait with publishing this fix, I will involved Oracle security, because this is an issue in their code. I will also split off a second bug, because these are two separate security issues.
I have applied your patch for vboxautostart.sh and am waiting for you to contact Oracle security. I hope the wait is not too long as I need to fix boo#1184392.
For completeness, this is what i wrote to Oracle about this issue: Hello Oracle Security, I have recently discovered a packaging issue in the virtualbox package shipped with openSUSE [1]. Our package maintainer(s) have setup the directory /etc/vbox with permissions of drwxrwxr-x 2 root vboxusers 4096 8. Apr 14:33 /etc/vbox This somehow resulted from the desire to enable the autostart feature for members of the "vboxusers" group. Members of this group should be able to create files like /etc/vbox/<username>.start to have their VMs started automatically during boot. The way this directory was packaged in openSUSE allowed for a local root exploit, however, because members of the vboxusers group have been able to remove and create arbitrary files in /etc/vbox, including recreating /etc/vbox/vbox.cfg, which is sourced by scripts running as the root user. A reproducer works like this: # emulate a malicious user that is member of the vboxusers group root# su -g vboxusers nobody nobody$ cd /etc/vbox # replace the original file by one that is writable by us nobody$ cp vbox.cfg vbox.cfg.new nobody$ rm -f vbox.cfg nobody$ mv vbox.cfg.new vbox.cfg # add malicious code to the configuration file nobody$ echo "touch /root/evil" >>vbox.cfg nobody$ exit # start the vboxautostart service to have the malicous code executed root# systemctl start vboxautostart.service root# ls -lh /root/evil -rw-r--r-- 1 root root 0 2. Mär 12:14 /root/evil The vboxautostart related files have been extracted by our maintainer(s) from the virtualbox.org distribution tarballs. I consider this issue to be openSUSE specific, because the sticky bit was missing from the directory permissions, contrary to what the VirtualBox manual says in doc/manual/en_US/user_AdvancedTopics.xml: ``` The directory should have write access for every user who should be able to start virtual machines automatically. Furthermore the directory should have the sticky bit set. ``` With the sticky bit set a member of the group will not be able to remove the existing "vbox.cfg" file and will not be able to modify its contents. I checked a couple of other Linux distributions and could not find this error reproduced elsewhere. Still I want to make you aware of this in case you know of any further instances where this issue could be present. We will assign a CVE to keep track of this issue and will publish the finding soon.
Please use CVE-2021-25319 for this issue
This bug is addressed by the same submissions that are referenced in bug 1184542.
I published a report about this on the oss-security mailing list: https://www.openwall.com/lists/oss-security/2021/04/26/2
This is an autogenerated message for OBS integration: This bug (1182918) was mentioned in https://build.opensuse.org/request/show/890867 15.2 / virtualbox
openSUSE-SU-2021:0723-1: An update that fixes 20 vulnerabilities is now available. Category: security (important) Bug References: 1182918 CVE References: CVE-2021-2145,CVE-2021-2250,CVE-2021-2264,CVE-2021-2266,CVE-2021-2279,CVE-2021-2280,CVE-2021-2281,CVE-2021-2282,CVE-2021-2283,CVE-2021-2284,CVE-2021-2285,CVE-2021-2286,CVE-2021-2287,CVE-2021-2291,CVE-2021-2296,CVE-2021-2297,CVE-2021-2306,CVE-2021-2309,CVE-2021-2310,CVE-2021-2312 JIRA References: Sources used: openSUSE Leap 15.2 (src): virtualbox-6.1.22-lp152.2.24.2, virtualbox-kmp-6.1.22-lp152.2.24.2
This is an autogenerated message for OBS integration: This bug (1182918) was mentioned in https://build.opensuse.org/request/show/897648 15.3 / virtualbox
openSUSE-SU-2021:0977-1: An update that fixes 20 vulnerabilities is now available. Category: security (important) Bug References: 1182918,1186361 CVE References: CVE-2021-2145,CVE-2021-2250,CVE-2021-2264,CVE-2021-2266,CVE-2021-2279,CVE-2021-2280,CVE-2021-2281,CVE-2021-2282,CVE-2021-2283,CVE-2021-2284,CVE-2021-2285,CVE-2021-2286,CVE-2021-2287,CVE-2021-2291,CVE-2021-2296,CVE-2021-2297,CVE-2021-2306,CVE-2021-2309,CVE-2021-2310,CVE-2021-2312 JIRA References: Sources used: openSUSE Leap 15.3 (src): virtualbox-6.1.22-lp153.2.3.2, virtualbox-kmp-6.1.22-lp153.2.3.2