Qualys has identified a third severe vulnerability this year (CVE-2022-3328) in the snap-confine utility, which comes with the SUID root flag and is called by the snapd process to form an executable environment for applications distributed in self-contained packages in the snap format. The vulnerability allows a local unprivileged user to achieve code execution as root in the default Ubuntu configuration. The issue has been fixed in the release of snapd 2.57.6. Package updates have been released for all supported branches of Ubuntu.
Interestingly, the vulnerability in question was introduced in the process of fixing a similar February vulnerability in snap-confine. The researchers were able to prepare a working exploit that provides root access in Ubuntu Server 22.04, which, in addition to the snap-confine vulnerability, also involves two vulnerabilities in the multipathd process (CVE-2022-41974, CVE-2022-41973) related to bypassing permissions when passing 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 substitution of the /tmp/snap.$SNAP_NAME directory for a symbolic link after the owner check, but before the mount system call is called to bind-mount directories into it for a package in snap format. The security added was to rename the /tmp/snap.$SNAP_NAME directory to another directory in /tmp with a random name if it exists and is not owned by the root user.
When exploiting the /tmp/snap.$SNAP_NAME directory rename operation, the researchers took advantage of the fact that snap-confine also creates a /tmp/snap.rootfs_XXXXXX directory for the root of the contents of the snap package. The "XXXXXX" part of the name is chosen randomly by mkdtemp(), but a package named "rootfs_XXXXXX" can pass sc_instance_name_validate (i.e. the idea is to have $SNAP_NAME set to "rootfs_XXXXXX" and then the rename operation will result in to overwriting the /tmp/snap.rootfs_XXXXXX directory with the snap root).
In order to achieve simultaneous use of /tmp/snap.rootfs_XXXXXX and renaming /tmp/snap.$SNAP_NAME, two instances of snap-confine were started. As soon as the first instance created /tmp/snap.rootfs_XXXXXX, the process would block and a second instance with the package name rootfs_XXXXXX would start, causing the second instance's temporary directory /tmp/snap.$SNAP_NAME to become the /tmp/snap.rootfs_XXXXXX root directory of the first instance. Immediately after the rename was performed, the second instance crashed, and /tmp/snap.rootfs_XXXXXX was replaced with race condition manipulation, as in the exploitation of the February vulnerability. After the change, the execution lock was removed from the first instance and the attackers gained full control over the snap root directory.
The last step was to create a symlink /tmp/snap.rootfs_XXXXXX/tmp which was used by the sc_bootstrap_mount_namespace() function to bind-mount the writable real directory /tmp to any directory in the file system, since the mount() call follows symlinks before mounting. Such mounting is blocked by AppArmor restrictions, but to bypass this blocking, the exploit exploited two auxiliary vulnerabilities in multipathd.
Source: opennet.ru