Bugzilla – Bug 1184542
VUL-0: CVE-2021-2264: virtualbox: vboxautostart.sh allows injection of parameters to 'su' invocation
Last modified: 2021-05-01 01:21:10 UTC
+++ This bug was initially created as a clone of Bug #1182918 This is a spin-off finding from bug 1182918 comment 3. I involved Oracle upstream about this, because the vboxautostart.sh script is coming from their upstream distribution. I wrote the following report to Oracle: A related issue that I do *not* consider openSUSE specific is the logic in the "vboxautostart-service.sh" file. The current version from release 6.1.18 uses the following loop in its `start()` function: ``` for user in `ls $VBOXAUTOSTART_DB/*.start` do start_daemon `basename $user | sed -ne "s/\(.*\).start/\1/p"` $binary $PARAMS > /dev/null 2>&1 done [...] start_daemon() { usr="$1" shift su - $usr -c "$*" } ``` Since by design unprivileged users need to have write access to this directory (even with the sticky bit set), an unprivileged user can create arbitrarily named new files that will be processed by the for loop above. If a user creates a file like "$VBOXAUTOSTART_DB/--evil.start", then the for loop will pass "--evil" as parameter to `start_daemon()`, resulting in the command line flag `--evil` being passed to the `su` utility. A reproducer for the openSUSE package (which uses an older but similarly vulnerable version of the vboxautostart script) looks like this: # emulate a malicious user that is a member of the vboxusers group root# su -g vboxusers nobody nobody$ cd /etc/vbox # try to inject a parameter to 'su' nobody$ touch -- '-s myshell.start' nobody$ exit # execute the autostart script root# /usr/lib/virtualbox/vboxautostart.sh start vboxautostart.sh: Starting VirtualBox VMs configured for autostart. vboxautostart.sh: Starting VMs for user -s myshell. # execution fails, because we cannot embed '/' characters in # filenames 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 '/' characters, therefore we cannot specify any valid executable beyond the CWD (usually "/") 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 settings 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). To fix this I suggest the following bugfix: - filter out unexpected characters from the username string e.g. by limiting it to alphanumeric characters. - check whether the resulting username is a valid username in the system. If not, abort. - check whether the owner of the *.start file is the same as the name of the file, refuse to process it otherwise. I am reporting this privately to you to allow for coordinated disclosure. The latest publication date of this finding due to our policies is 2021-05-31.
My suggested bugfix for this is in attachment 848123 [details]. While compiling the report for Oracle I noticed that our vboxautostart.sh is outdated by now and the upstream tarball for version 6.1.18 contains a newer version of the script, that is also vulnerable, however. @Larry: you don't need to do anything for this bug at the moment. I will inform you in this bug when I have news from Oracle.
I just received an email from Oracle security that a critical patch update scheduled for April 20 will contain a fix for this issue. Here are the full details: ``` The following issue reported by you has been addressed in the upcoming Critical Patch Update, due to be released at 1:00 PM, U.S. Pacific Time, on April 20, 2021. We ask that any information that you plan to publish regarding this issue be released after this date and time. S1451656/CVE-2021-2264: * Subject: VBOXAUTOSTART-SERVICE * CVSSv3.1 Base Score: 8.4 * CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N * Credited As: Matthias Gerstner of SUSE Please let us know if you have any questions or concerns with this report. Thank you for reporting this issue to Oracle. ```
@Larry: I suggest you prepare a submission containing the bugfix for this and submit it on 2021-04-21 into OBS. You should also submit a maintenance update for Leap 15.2. For the maintenance update you can use my patch from attachment 848123 [details]. For Factory you can for now use the patch or you can take whatever Oracle will be releasing with their update from the upstream tarball. Please also reference all CVEs in the package changelog (for this bug and for bug 1182918. I will add the CVE information to both bugs today.
VirtualBox has started rolling out V6.1.20. Their openSUSE RPM package is available; however, the tarball that we use to build our packages is still not available. I installed the RPM package. It sets /etc/vbox to be owned by root:root with permissions 0755. They do not install anything in /etc/default/virtualbox and make no provisions for VBOXAUTOSTART_DB other than to note that the referenced directory must be writable by all users that can autostart VMs, and the sticky bit must be set. The previous changes I made in out packages meet this requirement. The start code in their autostart service has the following: start() { [ -z "$VBOXAUTOSTART_DB" ] && exit 0 [ -z "$VBOXAUTOSTART_CONFIG" ] && exit 0 begin_msg "Starting VirtualBox VMs configured for autostart" console; vboxdrvrunning || { fail_msg "VirtualBox kernel module not loaded!" exit 0 } PARAMS="--background --start --config $VBOXAUTOSTART_CONFIG" # prevent inheriting this setting to VBoxSVC unset VBOX_RELEASE_LOG_DEST for entry in "$VBOXAUTOSTART_DB"/*.start do user=$(basename "$entry" .start) [ "$user" = "*" ] && break valid_db_entry "$entry" "$user" || continue start_daemon "$user" "$binary" $PARAMS > /dev/null 2>&1 done return $RETVAL } To my eye, the 'user=$(basename "$entry" .start)' does what your changes accomplished, namely to strip out the user from .start files in VBOXAUTOSTART_DB. I propose to substitute this version of vboxautostart.sh for the one that we are currently using. I will attach the complete file for your perusal.
Created attachment 848562 [details] Oracles new autostart shell routine
(In reply to Larry.Finger@gmail.com from comment #8) > I installed the RPM package. It sets /etc/vbox to be owned by root:root with > permissions 0755. They do not install anything in /etc/default/virtualbox > and make no provisions for VBOXAUTOSTART_DB other than to note that the > referenced directory must be writable by all users that can autostart VMs, > and the sticky bit must be set. The previous changes I made in out packages > meet this requirement. But you stick to the /etc/vbox/autostart.d directory, yes? Mixing the /etc/vbox/vbox.cfg and the *.start files in the same directory should be avoided. For migration you can add a %post scriptlet in the RPM spec file that moves /etc/vbox/*.start to /etc/vbox/autostart.d. > The start code in their autostart service has the following: [...] > To my eye, the 'user=$(basename "$entry" .start)' does what your changes > accomplished, namely to strip out the user from .start files in > VBOXAUTOSTART_DB. I propose to substitute this version of vboxautostart.sh > for the one that we are currently using. I will attach the complete file for > your perusal. The actual fix is in the `valid_db_entry` function call. It checks that the user is valid and that the file is also owned by the named user. Using this new script is fine. Please go ahead.
(In reply to Matthias Gerstner from comment #10) > But you stick to the /etc/vbox/autostart.d directory, yes? Mixing the > /etc/vbox/vbox.cfg and the *.start files in the same directory should be > avoided. I do not understand your comment. The start files are in /etc/vbox/autostart.d/ and vbox.cfg is in /etc/vbox/. Would you prefer the *.start files in some other place such as /etc/virtualbox/autostart.d/?
(In reply to Larry.Finger@gmail.com from comment #11) > (In reply to Matthias Gerstner from comment #10) > > But you stick to the /etc/vbox/autostart.d directory, yes? Mixing the > > /etc/vbox/vbox.cfg and the *.start files in the same directory should be > > avoided. > > I do not understand your comment. The start files are in > /etc/vbox/autostart.d/ and vbox.cfg is in /etc/vbox/. Then everything is good.
This is an autogenerated message for OBS integration: This bug (1184542) was mentioned in https://build.opensuse.org/request/show/888117 15.3 / virtualbox
The changes needed to fix this vulnerability have been submitted to Tumbleweed, Leap 15.3 and Leap 15.2. I am closing this bug report.
This is an autogenerated message for OBS integration: This bug (1184542) was mentioned in https://build.opensuse.org/request/show/888240 15.2 / virtualbox
I published a report about this on the oss-security mailing list: https://www.openwall.com/lists/oss-security/2021/04/26/1
openSUSE-SU-2021:0630-1: An update that solves three vulnerabilities and has two fixes is now available. Category: security (important) Bug References: 1181197,1181198,1183125,1183329,1184542 CVE References: CVE-2021-2074,CVE-2021-2129,CVE-2021-2264 JIRA References: Sources used: openSUSE Leap 15.2 (src): virtualbox-6.1.20-lp152.2.21.1, virtualbox-kmp-6.1.20-lp152.2.21.1