Bug 1184542 - (CVE-2021-2264) VUL-0: CVE-2021-2264: virtualbox: vboxautostart.sh allows injection of parameters to 'su' invocation
(CVE-2021-2264)
VUL-0: CVE-2021-2264: virtualbox: vboxautostart.sh allows injection of parame...
Status: RESOLVED FIXED
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Audits
unspecified
Other Other
: P5 - None : Normal
: ---
Assigned To: Larry Finger
Security Team bot
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2021-04-09 08:10 UTC by Matthias Gerstner
Modified: 2021-05-01 01:21 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Oracles new autostart shell routine (4.04 KB, text/plain)
2021-04-20 19:21 UTC, Larry Finger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Gerstner 2021-04-09 08:10:01 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.
Comment 2 Matthias Gerstner 2021-04-09 08:13:18 UTC
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.
Comment 5 Matthias Gerstner 2021-04-19 08:10:32 UTC
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.
```
Comment 7 Matthias Gerstner 2021-04-19 08:15:40 UTC
@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.
Comment 8 Larry Finger 2021-04-20 19:18:10 UTC
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.
Comment 9 Larry Finger 2021-04-20 19:21:04 UTC
Created attachment 848562 [details]
Oracles new autostart shell routine
Comment 10 Matthias Gerstner 2021-04-21 07:56:12 UTC
(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.
Comment 11 Larry Finger 2021-04-21 17:35:28 UTC
(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/?
Comment 12 Matthias Gerstner 2021-04-22 07:42:13 UTC
(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.
Comment 14 OBSbugzilla Bot 2021-04-24 01:00:06 UTC
This is an autogenerated message for OBS integration:
This bug (1184542) was mentioned in
https://build.opensuse.org/request/show/888117 15.3 / virtualbox
Comment 15 Larry Finger 2021-04-24 16:59:41 UTC
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.
Comment 16 OBSbugzilla Bot 2021-04-24 17:30:06 UTC
This is an autogenerated message for OBS integration:
This bug (1184542) was mentioned in
https://build.opensuse.org/request/show/888240 15.2 / virtualbox
Comment 17 Matthias Gerstner 2021-04-27 07:15:24 UTC
I published a report about this on the oss-security mailing list:

https://www.openwall.com/lists/oss-security/2021/04/26/1
Comment 18 Swamp Workflow Management 2021-05-01 01:21:10 UTC
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