{"id":103374,"date":"2022-02-18T03:37:22","date_gmt":"2022-02-18T01:37:22","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/lokalnye-root-uyazvimosti-v-instrumentarii-upravleniya-paketami-snap"},"modified":"2022-02-18T03:37:22","modified_gmt":"2022-02-18T01:37:22","slug":"lokalnye-root-uyazvimosti-v-instrumentarii-upravleniya-paketami-snap","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/lokalnye-root-uyazvimosti-v-instrumentarii-upravleniya-paketami-snap","title":{"rendered":"Local root vulnerabilities in the Snap package management toolkit","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Qualys has discovered two vulnerabilities (CVE-2021-44731, CVE-2021-44730) in the snap-confine utility, which is distributed with the SUID root flag and invoked by the snapd process to create the execution environment for applications supplied in self-contained packages in the snap format. The vulnerabilities allow a local unprivileged user to execute code with root privileges in the system. The issues have been resolved in today\u2019s snapd package update for Ubuntu 21.10, 20.04, and 18.04. <\/p>\n
The first vulnerability (CVE-2021-44730) allows an attack through manipulation of hard links, but requires disabling the system's hard link protection (setting sysctl fs.protected_hardlinks to 0). The issue is caused by inadequate checking of the locations of the executable files for the snap-update-ns and snap-discard-ns helper tools, which are run with root privileges. The path to these files was calculated in the sc_open_snapd_tool() function based on its own path from \/proc\/self\/exe, allowing the creation of a hard link to snap-confine in the attacker's directory and placing their versions of snap-update-ns and snap-discard-ns in this directory. Running snap-confine through the hard link with root privileges would execute snap-update-ns and snap-discard-ns files from the current directory supplied by the attacker. <\/p>\n
The second vulnerability is caused by a race condition and can be exploited in the default configuration of Ubuntu Desktop. To successfully run the exploit on Ubuntu Server, one of the packages from the 'Featured Server Snaps' section must be selected during installation. The race condition manifests in the setup_private_mount() function, which is called while preparing the namespace for mount points for snap packages. This function creates a temporary directory '\/tmp\/snap.$SNAP_NAME\/tmp' or uses an already existing one to bind-mount directories for the snap package. <\/p>\n
Since the name of the temporary directory is predictable, an attacker can substitute its content with a symbolic link at a moment after owner verification but before the system call to mount is executed. For instance, a symbolic link '\/tmp\/snap.lxd\/tmp' can be created in the \/tmp\/snap.lxd directory, pointing to an arbitrary directory, and the mount() call will follow the symbolic link, mounting that directory in the snap namespace. Similarly, one can mount their content in \/var\/lib and replace \/var\/lib\/snapd\/mount\/snap.snap-store.user-fstab to mount their \/etc directory in the snap package's namespace to load their library with root privileges by replacing \/etc\/ld.so.preload. <\/p>\n
It is noted that creating the exploit proved to be a non-trivial task since the snap-confine utility is written in Go using safe programming practices, has protection based on AppArmor profiles, filters system calls using the seccomp mechanism, and applies namespaces for mounting for isolation. Nonetheless, researchers managed to prepare a working exploit to gain root privileges on the system. The exploit code will be published in a few weeks, after users have installed the provided updates. \n Source: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"