Om de utnyttjas kan dessa brister tillåta angripare att få obehörig åtkomst till känslig information eller i allmänhet orsaka problem
För några dagar sedan kom nyheten om det en sårbarhet upptäcktes (redan listad under CVE-2023-4273) i drivrutinen för exFAT-filsystemet levereras i Linux-kärnan.
Problemeta ligger i det faktum att styrenheten tillåter montering av en specialdesignad skiljevägg, (till exempel genom att koppla in en skadlig USB-flash), slå ett stackspill och kör din kod med kärnrättigheter.
Problemet är: koden förutsätter att filnamnsinmatningar alltid producerar ett sammanlänkade filnamn som rymmer 255 tecken (gränsen är 258 tecken, inkluderar 1 extra tecken för en nollbyte och 2 extra tecken för konvertering). Att lagra mer än 255 tecken i filnamnet i en uppsättning katalogposter är en överträdelse av filsystemets format, men accepteras av Linux-drivrutinen, men orsakar också ett stackspill (eftersom filnamnet är sammanfogat till en variabel som allokeras av stacken).
Angående sårbarhet nämns att, detta ochs utnyttjas på grund av storlekskontrollfel kopiering av ett filnamn till en stack-allokerad buffert resulterar i ett kärnstackspill om ett mycket långt filnamn tillhandahålls som överskrider filsystemgränsen på 255 tecken.
Funktionen exfat_extract_uni_name() slutar kopiera tecken till destinationsbufferten när ett nolltecken (0x0000) påträffas och returnerar antalet kopierade tecken. Men den som ringer ignorerar returvärdet och flyttar fram pekaren 15 tecken (30 byte) för nästa iteration. Därför är det möjligt att hoppa över (låt vara intakta) 14 tecken eller 28 byte i en iteration.
Sårbarhet finns i en funktion som utför lång namnrekonstruktion cykliskt läsa poster med filnamnsdelar från katalogindexet och slå samman de resulterande namndelarna till det slutliga långa namnet.
Storlekskontrollen i koden för den funktionen utfördes i förhållande till varje post med en namndel, men täckte inte det slutliga namnet (namnet kan till exempel delas upp i 100 delar och nå 1500 tecken istället för 258 tecken i bufferten ).
Utredaren som upptäckte sårbarheten kunde förbereda en prototypexploat vilket gör att du kan öka dina privilegier på systemet. När den testas på en VirtualBox virtuell maskin fungerar exploateringen 100 % av tiden, men när den körs i en normal miljö som körs ovanpå hårdvara, sjunker chansen att den utlöses till cirka 50 %.
I synnerhet skriver min exploit över en stackallokerad pekare till en nollterminerad sträng, så följande försök att lägga till ett avslutande nolltecken till denna sträng blir faktiskt det primitiva "skriv en nollbyte till minnesplatsen som valts av angriparen.
Det nämns också att sårbarheten kan användas för att äventyra kärnor som startats i UEFI Secure Boot-läge, eftersom den nämner att en bild som innehåller en sårbar kärna, med ett motsvarande init-skript (och exploateringen, naturligtvis), som startar före ett riktigt operativsystem, placeras på en startbar enhet. När den startas laddar den här bilden en skadlig (och osignerad) kärnmodul, som etablerar dess kontroll över kärnläget och sedan växlar till det verkliga operativsystemet (till exempel med hjälp av kexec-anropet).
Slutligen är det värt att nämna att problemet åtgärdades i de versioner av Linux som fortfarande stöds. Vid tidpunkten för avslöjandet av sårbarheten var den senaste versionen av Linux Kernel Linux version 6.4.10, men den nya versionen 6.5 har redan korrigeringen.
För de som är intresserade av att spåra lösningen i de olika distributionerna kan de göra det från följande sidor: Debian, ubuntu, RHEL, SUSE y Fedora.
Om du är det intresserad av att veta mer om det, Du kan kontrollera detaljerna i följande länk.