Rotsårbarhet i Linux-kärnan och denial of service i systemd

Säkerhetsforskare från Qualys har avslöjat detaljer om två sårbarheter som påverkar Linux-kärnan och systemd-systemhanteraren. En sårbarhet i kärnan (CVE-2021-33909) tillåter en lokal användare att uppnå kodexekvering med roträttigheter genom manipulering av mycket kapslade kataloger.

Faran för sårbarheten förvärras av det faktum att forskarna kunde förbereda fungerande exploateringar som fungerar på Ubuntu 20.04/20.10/21.04, Debian 11 och Fedora 34 i standardkonfigurationen. Det noteras att andra distributioner inte har testats, men är teoretiskt också mottagliga för problemet och kan attackeras. Den fullständiga koden för utnyttjandet lovas att publiceras efter att problemet har eliminerats överallt, men för närvarande är endast en prototyp av begränsad funktionalitet tillgänglig, vilket får systemet att krascha. Problemet har funnits sedan juli 2014 och påverkar kärnutgåvor från och med 3.16. Sårbarhetskorrigeringen samordnades med communityn och accepterades i kärnan den 19 juli. Huvuddistributionerna har redan genererat uppdateringar till sina kärnpaket (Debian, Ubuntu, Fedora, RHEL, SUSE, Arch).

Sårbarheten orsakas av misslyckande att kontrollera resultatet av en size_t till int-konvertering innan operationer utförs i seq_file-koden, som skapar filer från en sekvens av poster. Underlåtenhet att kontrollera kan resultera i out-of-bounds skrivningar till bufferten när en mycket kapslad katalogstruktur skapas, monteras och tas bort (sökväg större än 1 GB). Som ett resultat kan en angripare uppnå en 10-byte-sträng "//deleted" skriven med en offset på "-2 GB - 10 bytes" som pekar på området omedelbart före den tilldelade bufferten.

Den förberedda exploateringen kräver 5 GB minne och 1 miljon lediga inoder för att fungera. Exploateringen fungerar genom att anropa mkdir() för att skapa en hierarki på cirka en miljon underkataloger för att uppnå en filsökvägsstorlek som överstiger 1 GB. Denna katalog monteras via bind-mount i ett separat användarnamnområde, varefter funktionen rmdir() körs för att ta bort den. Parallellt skapas en tråd som laddar ett litet eBPF-program, som blockeras i skedet efter kontroll av eBPF-pseudokoden, men innan dess JIT-kompilering.

I det oprivilegierade användar-id-namnutrymmet öppnas filen /proc/self/mountinfo och det långa sökvägsnamnet för den bindmonterade katalogen läses, vilket resulterar i att strängen "//deleted" skrivs till området innan bufferten startade. Positionen för att skriva raden är vald så att den skriver över instruktionen i det redan testade men ännu inte kompilerade eBPF-programmet.

Därefter, på eBPF-programnivå, omvandlas okontrollerad skrivning utanför bufferten till kontrollerad förmåga att läsa och skriva till andra kärnstrukturer genom manipulering av btf- och map_push_elem-strukturerna. Som ett resultat bestämmer utnyttjandet platsen för modprobe_path[]-bufferten i kärnminnet och skriver över "/sbin/modprobe"-sökvägen i den, vilket gör att du kan initiera lanseringen av valfri körbar fil med roträttigheter i händelse av en request_module()-anrop, som exekveras till exempel när en nätlänkssocket skapas.

Forskare tillhandahåller flera lösningar som endast är effektiva för ett specifikt utnyttjande, men som inte eliminerar själva problemet. Det rekommenderas att ställa in "/proc/sys/kernel/unprivileged_userns_clone" till 0 för att inaktivera montering av kataloger i ett separat användar-ID-namnområde, och "/proc/sys/kernel/unprivileged_bpf_disabled" till 1 för att inaktivera inläsning av eBPF-program i kärnan.

Det är anmärkningsvärt att samtidigt som forskarna analyserade en alternativ attack som involverade användningen av FUSE-mekanismen istället för bind-mound för att montera en stor katalog, stötte forskarna på en annan sårbarhet (CVE-2021-33910) som påverkar systemd-systemhanteraren. Det visade sig att när man försöker montera en katalog med en sökväg som överstiger 8 MB via FUSE, tar kontrollinitieringsprocessen (PID1) slut på stackminne och kraschar, vilket försätter systemet i ett "panik"-tillstånd.

Problemet är att systemd spårar och analyserar innehållet i /proc/self/mountinfo, och bearbetar varje monteringspunkt i funktionen unit_name_path_escape(), som utför en strdupa()-operation som placerar data på stacken snarare än i dynamiskt allokerat minne . Eftersom den maximala stackstorleken är begränsad via RLIMIT_STACK, orsakar behandling av en för stor sökväg till monteringspunkten att PID1-processen kraschar och stoppar systemet. För en attack kan du använda den enklaste FUSE-modulen i kombination med att använda en mycket kapslad katalog som monteringspunkt, vars sökvägsstorlek överstiger 8 MB.

Problemet har dykt upp sedan systemd 220 (april 2015), har redan fixats i systemd-förrådet och fixat i distributioner (Debian, Ubuntu, Fedora, RHEL, SUSE, Arch). Noterbart, i systemd release 248 fungerar inte exploateringen på grund av en bugg i systemd-koden som gör att bearbetningen av /proc/self/mountinfo misslyckas. Det är också intressant att under 2018 uppstod en liknande situation och när de försökte skriva en exploatering för CVE-2018-14634 sårbarheten i Linux-kärnan, stötte Qualys-forskare på tre kritiska sårbarheter i systemd.

Källa: opennet.ru

Lägg en kommentar