Qualys har identificeret en tredje alvorlig sårbarhed (CVE-2022-3328) i værktøjet snap-confine, som leveres med SUID root-flaget og kaldes af snapd-processen for at danne det udførelsesmiljø, som applikationer distribueres i via selvstændige pakker i snap-format. Sårbarheden giver en lokal, ikke-privilegeret bruger mulighed for at udføre kode med root-rettigheder i standard Ubuntu-konfigurationen. Problemet er blevet rettet i versionen snapd 2.57.6. Updates er blevet udgivet for alle understøttede Ubuntu-versioner.
Det er interessant, at den aktuelle sårbarhed blev indført som en del af rettelsen af en lignende sårbarhed i snap-confine fra februar. Forskere lykkedes med at udarbejde et funktionelt exploit, der giver root-adgang i Ubuntu Server 22.04, og i denne sårbarhed er der også to sårbarheder i multipathd-processen (CVE-2022-41974, CVE-2022-41973), relateret til omgåelse af adgangskontrol ved overførsel af privilegerede kommandoer og usikker håndtering af symbolske links.
Sårbarheden i snap-confine skyldes en kapløbssituation i funktionen must_mkdir_and_open_with_perms(), der blev tilføjet for at beskytte mod at kataloget /tmp/snap.$SNAP_NAME bliver ændret til et symbolsk link efter ejerkontrollen, men før kaldet til systemopkaldet mount for bind-mounting af kataloger til snap-pakken. Den tilføjede beskyttelse bestod i at omdøbe kataloget /tmp/snap.$SNAP_NAME til et andet katalog i /tmp med et tilfældigt navn, hvis det eksisterer og ikke tilhører brugeren root.
Under udnyttelsen af omdøbningsoperationen af kataloget /tmp/snap.$SNAP_NAME udnyttede forskerne, at snap-confine også opretter kataloget /tmp/snap.rootfs_XXXXXX for rodindholdet af snap-pakken. Delen "XXXXXX" i navnet vælges tilfældigt ved hjælp af mkdtemp(), men pakken med navnet "rootfs_XXXXXX" kan bestå kontrollen i funktionen sc_instance_name_validate (dvs. ideen er, at navnet $SNAP_NAME kan antage værdien "rootfs_XXXXXX" og så vil omdøbningsoperationen føre til overskrivning af kataloget /tmp/snap.rootfs_XXXXXX med rod for snap).
For simultaneous use of /tmp/snap.rootfs_XXXXXX and renaming /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, causing the temporary directory /tmp/snap.$SNAP_NAME of the second instance to become the root directory /tmp/snap.rootfs_XXXXXX of the first. Immediately after performing the renaming, the second instance crashed, and /tmp/snap.rootfs_XXXXXX was replaced with a race condition manipulation, as seen in the February vulnerability exploitation. After the replacement, execution blocking was lifted from the first instance, allowing 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.
Kilde: opennet.ru
