{"id":104360,"date":"2022-06-12T09:36:50","date_gmt":"2022-06-12T07:36:50","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-v-firejail-pozvolyayushhaya-poluchit-root-dostup-v-sisteme"},"modified":"2022-06-12T09:36:50","modified_gmt":"2022-06-12T07:36:50","slug":"uyazvimost-v-firejail-pozvolyayushhaya-poluchit-root-dostup-v-sisteme","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/news\/uyazvimost-v-firejail-pozvolyayushhaya-poluchit-root-dostup-v-sisteme","title":{"rendered":"S\u00e5rbarhed i firejail, der tillader root-adgang til systemet","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
I v\u00e6rkt\u00f8jet til isoleret udf\u00f8relse af applikationer Firejail er der opdaget en s\u00e5rbarhed (CVE-2022-31214), der g\u00f8r det muligt for en lokal bruger at opn\u00e5 root-rettigheder i det prim\u00e6re system. Der findes en fungerende exploit tilg\u00e6ngelig offentligt, testet i de aktuelle versioner af openSUSE, Debian, Arch, Gentoo og Fedora med det installerede firejail-v\u00e6rkt\u00f8j. Problemet er blevet l\u00f8st i firejail-version 0.9.70. Som en midlertidig beskyttelsesforanstaltning kan man i indstillingerne (\\\/etc\\\/firejail\\\/firejail.config) aktivere parametrene \"join no\" og \"force-nonewprivs yes\". <\/p>\n
Firejail bruger mekanismer til navnerum (namespaces), AppArmor og filtrering af systemopkald (seccomp-bpf) i Linux til isolering, men kr\u00e6ver forh\u00f8jede rettigheder til konfiguration af isoleret udf\u00f8relse, som opn\u00e5s via tilknytning til v\u00e6rkt\u00f8jet med suid root-flaget eller ved at blive k\u00f8rt med sudo. S\u00e5rbarheden er for\u00e5rsaget af en fejl i logikken af optionen \"--join=\", der er designet til at forbinde til et allerede k\u00f8rende isoleret milj\u00f8 (svarende til login-kommandoen for sandbox-milj\u00f8et) med bestemmelse af milj\u00f8et ud fra det k\u00f8rende proces-ID. Inden privilegierne skal tildeles p\u00e5 ny, bestemmer firejail privilegierne for den angivne proces og anvender dem p\u00e5 den nye proces, der forbindes til milj\u00f8et ved hj\u00e6lp af optionen \"--join\". <\/p>\n
Inden forbindelsen oprettes, kontrolleres det, om den angivne proces k\u00f8rer i firejail-milj\u00f8et. Denne kontrol vurdere, om filen \\\/run\\\/firejail\\\/mnt\\\/join eksisterer. For at udnytte s\u00e5rbarheden kan angriberen simulere et falsk, ikke-isoleret firejail-milj\u00f8 ved at bruge mount namespace, hvorefter de kan forbinde til det ved hj\u00e6lp af optionen \"--join\". Hvis indstillingerne ikke har aktiveret tilstanden for at forhindre opn\u00e5else af yderligere privilegier i nye processer (prctl NO_NEW_PRIVS), vil firejail forbinde brugeren til det falske milj\u00f8 og fors\u00f8ge at anvende indstillingerne for bruger namespace af init-processen (PID 1). <\/p>\n
Som det er, vil den proces, der tilsluttes via «firejail —join», befinde sig i brugerens oprindelige ID-navnerum med u\u00e6ndrede privilegier, men i et andet monteringspunkt, som helt kontrolleres af angriberen. Blandt andet kan angriberen k\u00f8re setuid-root-programmer i det p\u00e5g\u00e6ldende monteringspunkt, hvilket g\u00f8r det muligt f.eks. at \u00e6ndre indstillingerne i \/etc\/sudoers eller PAM-parametre i sin egen filhierarki og opn\u00e5 mulighed for at udf\u00f8re kommandoer med root-rettigheder ved hj\u00e6lp af sudo- eller su-v\u00e6rkt\u00f8jerne. \n Kilde: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"