Qualys har identificeret den tredje farlige sårbarhed i år (CVE-2022-3328) i snap-confine-værktøjet, som kommer med SUID-rodflaget og kaldes af snapd-processen for at skabe et eksekverbart miljø for applikationer distribueret i selvstændige pakker i snap-formatet. Sårbarheden tillader en lokal uprivilegeret bruger at opnå kodekørsel som root i standard Ubuntu-konfigurationen. Problemet er løst i snapd 2.57.6-udgivelsen. Pakkeopdateringer er blevet frigivet til alle understøttede grene af Ubuntu.
Interessant nok blev den pågældende sårbarhed introduceret under processen med at rette en lignende februar-sårbarhed i snap-confine. Forskere var i stand til at forberede en fungerende udnyttelse, der giver root-adgang til Ubuntu Server 22.04, som ud over sårbarheden i snap-confine også involverer to sårbarheder i multipathd-processen (CVE-2022-41974, CVE-2022-41973) , forbundet med omgåelse af myndighedskontrollen ved transmission af privilegerede kommandoer og usikkert arbejde med symbolske links.
Sårbarheden i snap-confine er forårsaget af en race-tilstand i must_mkdir_and_open_with_perms()-funktionen, tilføjet for at beskytte mod substitution af mappen /tmp/snap.$SNAP_NAME med et symbolsk link efter at have tjekket ejeren, men før opkald til mount-systemet kald til bind-mount mapper ind i det for en pakke i snap-format. Den ekstra beskyttelse var at omdøbe mappen /tmp/snap.$SNAP_NAME til en anden mappe i /tmp med et tilfældigt navn, hvis den findes og ikke ejes af root.
Når forskerne udnyttede /tmp/snap.$SNAP_NAME-katalogomdøbningsoperationen, udnyttede forskerne det faktum, at snap-confine også opretter en /tmp/snap.rootfs_XXXXXX-mappe til roden af snap-pakkens indhold. "XXXXXX"-delen af navnet vælges tilfældigt af mkdtemp(), men en pakke med navnet "rootfs_XXXXXX" kan valideres i sc_instance_name_validate-funktionen (dvs. ideen er, at $SNAP_NAME vil blive sat til "rootfs_XXXXXX" og derefter omdøbe operationen vil resultere i at overskrive mappen /tmp/snap.rootfs_XXXXXX med root-snappen).
For at opnå samtidig brug af /tmp/snap.rootfs_XXXXXX og omdøbning af /tmp/snap.$SNAP_NAME, blev to forekomster af snap-confine lanceret. Når den første forekomst oprettede /tmp/snap.rootfs_XXXXXX, ville processen blokere, og en anden forekomst ville starte med pakkenavnet rootfs_XXXXXX, hvilket får den anden forekomsts midlertidige mappe /tmp/snap.$SNAP_NAME til at blive rodmappen /tmp/snap .rootfs_XXXXXX af de første. Umiddelbart efter omdøbningen var fuldført, styrtede den anden forekomst ned, og /tmp/snap.rootfs_XXXXXX blev erstattet med racetilstandsmanipulation, som ved udnyttelse af februar-sårbarheden. Efter udskiftningen blev udførelseslåsen fjernet fra første instans, og angriberne fik fuld kontrol over snap-rodmappen.
Det sidste trin var at oprette et symbollink /tmp/snap.rootfs_XXXXXX/tmp, som blev brugt af funktionen sc_bootstrap_mount_namespace() til at binde-mount den skrivbare rigtige mappe /tmp til en hvilken som helst mappe i filsystemet, da mount() kalder følger symbollinks inden montering. Sådan montering er blokeret af AppArmor-restriktioner, men for at omgå denne blokering brugte udnyttelsen to hjælpesårbarheder i multipathd.
Kilde: opennet.ru