Firma Qualys odkryła trzecią w tym roku niebezpieczną lukę (CVE-2022-3328) w narzędziu snap-confine, dostarczanym z flagą SUID root i wywoływanym przez proces snapd w celu utworzenia środowiska wykonawczego dla aplikacji, rozdawanych w samodzielnych pakietach w formacie snap. Luka pozwala lokalnemu użytkownikowi niewysokich uprawnień na uzyskanie wykonywania kodu z prawami root w domyślnej konfiguracji Ubuntu. Problem został rozwiązany w wersji snapd 2.57.6. Aktualizacje pakietów zostały wydane dla wszystkich wspieranych gałęzi Ubuntu.
Interesujące jest to, że omawiana luka została wprowadzona podczas naprawy podobnej luki z lutego dotyczącej snap-confine. Badacze byli w stanie przygotować działający eksploit, zapewniający dostęp root w Ubuntu Server 22.04, w którym poza luką w snap-confine zaangażowane są również dwie luki w procesie multipathd (CVE-2022-41974, CVE-2022-41973), związane z obejściem kontroli uprawnień podczas przekazywania uprzywilejowanych komend oraz niebezpiecznym posługiwaniu się linkami symbolicznymi.
Luka w snap-confine jest spowodowana stanem wyścigu w funkcji must_mkdir_and_open_with_perms(), dodanej w celu ochrony przed zastąpieniem katalogu /tmp/snap.$SNAP_NAME symlinkiem w momencie po sprawdzeniu właściciela, ale przed wywołaniem syscalls mount dla bind-montowania katalogów dla pakietu w formacie snap. Dodana ochrona polegała na zmianie nazwy katalogu /tmp/snap.$SNAP_NAME na inny katalog w /tmp o losowej nazwie, jeśli istnieje i nie należy do użytkownika root.
Podczas exploitacji operacji zmiany nazwy katalogu /tmp/snap.$SNAP_NAME badacze wykorzystali fakt, że snap-confine również tworzy katalog /tmp/snap.rootfs_XXXXXX dla rdzenia zawartości pakietu snap. Część „XXXXXX” w nazwie jest wybierana losowo przy pomocy mkdtemp(), ale pakiet o nazwie „rootfs_XXXXXX” może przejść weryfikację w funkcji sc_instance_name_validate (tj. idea polega na tym, aby nazwa $SNAP_NAME przyjęła wartość „rootfs_XXXXXX”, a wówczas operacja zmiany nazwy spowoduje nadpisanie katalogu /tmp/snap.rootfs_XXXXXX z rdzeniem snap).
Aby jednocześnie wykorzystać /tmp/snap.rootfs_XXXXXX i zmienić nazwę /tmp/snap.$SNAP_NAME, uruchomiono dwa instancje snap-confine. Gdy pierwsza instancja tworzyła /tmp/snap.rootfs_XXXXXX, proces był blokowany, a druga instancja uruchamiana była z nazwą pakietu rootfs_XXXXXX, co prowadziło do sytuacji, w której tymczasowy katalog /tmp/snap.$SNAP_NAME drugiej instancji stawał się katalogiem głównym /tmp/snap.rootfs_XXXXXX pierwszej. Zaraz po wykonaniu zmiany nazwy druga instancja zakończyła działanie awaryjnie, a /tmp/snap.rootfs_XXXXXX został podmieniony na skutek wyścigu stanów, jak w przypadku wykorzystywania lutowej podatności. Po podmianie blokada pierwszej instancji została zdjęta, a atakujący uzyskali pełną kontrolę nad katalogiem głównym snap.
Na ostatnim etapie utworzono dowiązanie symboliczne /tmp/snap.rootfs_XXXXXX/tmp, które było używane przez funkcję sc_bootstrap_mount_namespace() do montowania bind dostępnego do zapisu rzeczywistego katalogu /tmp w dowolnym katalogu systemu plików, ponieważ wywołanie mount() podąża za dowiązaniami symbolicznymi przed montowaniem. Takie montowanie jest blokowane przez ograniczenia AppArmor, ale dla ominięcia tej blokady w exploicie wykorzystano dwie powiązane podatności w multipathd.
Źródło: opennet.ru
