Local root vulnerabilities in the Snap package management toolkit

Qualys has identified two vulnerabilities (CVE-2021-44731, CVE-2021-44730) in the snap-confine utility, supplied with the SUID root flag and called by the snapd process to create an executable environment for applications delivered in self-contained packages in the snap format. The vulnerabilities allow a local unprivileged user to execute code with root privileges on the system. The issues are resolved in today's snapd package update for Ubuntu 21.10, 20.04 and 18.04.

The first vulnerability (CVE-2021-44730) allows an attack through hard link manipulation, but requires disabling system hard link protection (setting sysctl fs.protected_hardlinks to 0). The problem is caused by incorrect verification of the location of the executable files of the snap-update-ns and snap-discard-ns helper programs run as root. The path to these files was calculated in the sc_open_snapd_tool() function based on its own path from /proc/self/exe, which allows you to create a hard link to snap-confine in your directory and place your own versions of the snap-update-ns and snap- utilities in this directory discard-ns. After running via a hard link, snap-confine with root rights will launch the snap-update-ns and snap-discard-ns files from the current directory, substituted by the attacker.

The second vulnerability is caused by a race condition and can be exploited in the default Ubuntu Desktop configuration. For the exploit to work successfully in Ubuntu Server, you must select one of the packages from the β€œFeatured Server Snaps” section when installing. The race condition is evident in the setup_private_mount() function called during the preparation of the mount point namespace for the snap package. This function creates a temporary directory β€œ/tmp/snap.$SNAP_NAME/tmp” or uses an existing one to bind-mount directories for a snap package into it.

Since the name of the temporary directory is predictable, an attacker can replace its contents with a symbolic link after checking the owner, but before calling the mount system call. For example, you can create a symlink "/tmp/snap.lxd/tmp" in the /tmp/snap.lxd directory pointing to an arbitrary directory, and a call to mount() will follow the symlink and mount the directory in the snap namespace. In a similar way, you can mount your contents in /var/lib and, by replacing /var/lib/snapd/mount/snap.snap-store.user-fstab, organize the mounting of your /etc directory in the namespace of the snap package to organize loading of your library from with root rights by replacing /etc/ld.so.preload.

It is noted that creating an exploit turned out to be a non-trivial task, since the snap-confine utility is written in Go using secure programming techniques, has protection based on AppArmor profiles, filters system calls based on the seccomp mechanism, and uses the mount namespace for isolation. However, the researchers were able to prepare a working exploit to gain root rights on the system. The exploit code will be published in a few weeks after users install the provided updates.

Source: opennet.ru

Add a comment