Firma Qualys zidentyfikowała w tym roku trzecią poważną lukę (CVE-2022-3328) w narzędziu snap-confine, które jest dostarczane z flagą główną SUID i jest wywoływane przez proces snapd w celu utworzenia środowiska wykonywalnego dla aplikacji dystrybuowanych w samodzielnych pakietach w formacie snapa. Luka umożliwia lokalnemu, nieuprzywilejowanemu użytkownikowi wykonanie kodu jako root w domyślnej konfiguracji Ubuntu. Problem został rozwiązany w wersji snapd 2.57.6. Wydano aktualizacje pakietów dla wszystkich obsługiwanych gałęzi Ubuntu.
Co ciekawe, omawiana luka została wprowadzona w procesie naprawiania podobnej lutowej luki w snap-confine. Naukowcom udało się przygotować działający exploit zapewniający dostęp roota w Ubuntu Server 22.04, który oprócz luki umożliwiającej snap-confine zawiera także dwie luki w procesie wielościeżkowym (CVE-2022-41974, CVE-2022-41973). związane z omijaniem uprawnień podczas przekazywania uprzywilejowanych poleceń i niebezpieczną obsługą dowiązań symbolicznych.
Luka w snap-confine jest spowodowana sytuacją wyścigu w funkcji must_mkdir_and_open_with_perms(), dodaną w celu ochrony przed podstawieniem katalogu /tmp/snap.$SNAP_NAME dla dowiązania symbolicznego po sprawdzeniu właściciela, ale przed wywołaniem systemowym mount jest wywoływana w celu powiązania z nim katalogów dla pakietu w formacie snap. Dodane zabezpieczenie polegało na zmianie nazwy katalogu /tmp/snap.$SNAP_NAME na inny katalog w /tmp o losowej nazwie, jeśli istnieje i nie jest własnością użytkownika root.
Wykorzystując operację zmiany nazwy katalogu /tmp/snap.$SNAP_NAME, badacze wykorzystali fakt, że snap-confine tworzy również katalog /tmp/snap.rootfs_XXXXXX dla katalogu głównego zawartości pakietu snap. Część nazwy „XXXXXX” jest wybierana losowo przez mkdtemp(), ale pakiet o nazwie „rootfs_XXXXXX” może przekazać sc_instance_name_validate (tzn. pomysł jest taki, aby $SNAP_NAME był ustawiony na „rootfs_XXXXXX”, a następnie operacja zmiany nazwy spowoduje nadpisanie katalog /tmp/snap.rootfs_XXXXXX z katalogiem przyciągania).
Aby osiągnąć jednoczesne użycie /tmp/snap.rootfs_XXXXXX i zmianę nazwy /tmp/snap.$SNAP_NAME, uruchomiono dwie instancje snap-confine. Gdy tylko pierwsza instancja utworzy /tmp/snap.rootfs_XXXXXX, proces zostanie zablokowany i uruchomi się druga instancja o nazwie pakietu rootfs_XXXXXX, powodując, że katalog tymczasowy drugiej instancji /tmp/snap.$SNAP_NAME stanie się /tmp/snap .rootfs_XXXXXX katalog główny pierwszej instancji. Natychmiast po dokonaniu zmiany nazwy druga instancja uległa awarii, a plik /tmp/snap.rootfs_XXXXXX został zastąpiony manipulacją warunkami wyścigu, podobnie jak w przypadku wykorzystania luki z lutego. Po zmianie usunięto blokadę wykonania z pierwszej instancji, a atakujący uzyskali pełną kontrolę nad katalogiem głównym snapu.
Ostatnim krokiem było utworzenie dowiązania symbolicznego /tmp/snap.rootfs_XXXXXX/tmp, które zostało użyte przez funkcję sc_bootstrap_mount_namespace() do powiązania montowalnego rzeczywistego katalogu /tmp z dowolnym katalogiem w systemie plików, ponieważ następuje wywołanie mount() dowiązania symboliczne przed montażem. Takie montowanie jest blokowane przez ograniczenia AppArmor, ale aby ominąć to blokowanie, exploit wykorzystał dwie dodatkowe luki w zabezpieczeniach wielościeżkowych.
Źródło: opennet.ru