Qualys has identified a third critical vulnerability (CVE-2022-3328) this year in the snap-confine utility, delivered with the SUID root flag and invoked by the snapd process to create an execution environment for applications distributed in self-contained snap packages. The vulnerability allows a local unprivileged user to execute code with root privileges on the default Ubuntu configuration. The issue has been fixed in snapd version 2.57.6. Package updates have been released for all supported Ubuntu branches.
Interestingly, the vulnerability in question was introduced while fixing a similar vulnerability in snap-confine earlier in February. Researchers were able to prepare a working exploit providing root access on Ubuntu Server 22.04, which also involved two vulnerabilities in the multipathd process (CVE-2022-41974, CVE-2022-41973), associated with bypassing authorization checks during the execution of privileged commands and unsafe handling of symbolic links.
The vulnerability in snap-confine is caused by a race condition in the must_mkdir_and_open_with_perms() function, added to protect against the replacement of the directory /tmp/snap.$SNAP_NAME with a symbolic link at a moment after verifying the owner but before calling the mount system call to bind-mount the directories for the snap package. The added protection involved renaming the directory /tmp/snap.$SNAP_NAME to another directory in /tmp with a random name if it exists and does not belong to the root user.
During the exploitation of the renaming operation of the directory /tmp/snap.$SNAP_NAME, researchers leveraged the fact that snap-confine also creates the directory /tmp/snap.rootfs_XXXXXX for the root of the snap package contents. The part "XXXXXX" in the name is chosen randomly using mkdtemp(), but a package named "rootfs_XXXXXX" can pass validation in the function sc_instance_name_validate (i.e., the idea is for the name $SNAP_NAME to take on the value "rootfs_XXXXXX", and then the renaming operation will lead to the overwriting of the directory /tmp/snap.rootfs_XXXXXX with the snap root).
To achieve simultaneous use of /tmp/snap.rootfs_XXXXXX and renaming of /tmp/snap.$SNAP_NAME, two instances of snap-confine were launched. As soon as the first instance created /tmp/snap.rootfs_XXXXXX, the process was blocked, and the second instance with the package name rootfs_XXXXXX was started, leading to the temporary directory /tmp/snap.$SNAP_NAME of the second instance becoming the root directory /tmp/snap.rootfs_XXXXXX of the first. Immediately after the renaming, the second instance crashed, and /tmp/snap.rootfs_XXXXXX was substituted in a race condition manipulation, similar to the exploitation of the February vulnerability. After the substitution, the execution lock was lifted from the first instance, giving attackers full control over the root directory of the snap.
At the final stage, a symbolic link /tmp/snap.rootfs_XXXXXX/tmp was created, which was used by the function sc_bootstrap_mount_namespace() for bind-mounting the writable real directory /tmp into any FS directory, as the mount() call follows symbolic links before mounting. Such mounting is blocked by AppArmor restrictions, but to bypass this block, two auxiliary vulnerabilities in multipathd were exploited.
Source: opennet.ru
