Exploitatie van null-referenties in de Linux-kernel
Onlangs werd bekendgemaakt dat onderzoekers van het Google Project Zero-team een ​​methode hebben ontwikkeld om kwetsbaarheden in de Linux-kernel te misbruiken die worden veroorzaakt door het dereferentiëren van de NULL-pointer.
Tot nu toe hebben kernelproblemen met betrekking tot het dereferentiëren van NULL-pointers niet de nodige aandacht gekregen , omdat het onrealistisch werd geacht om dergelijke problemen om te zetten in aanvallen die leiden tot privilege-escalatie of het uitvoeren van eigen code (het toewijzen van processen zonder privileges aan het lagere gedeelte van de adresruimte is verboden).
In de regel leiden dergelijke fouten tot het genereren van oops-waarschuwingen door de kernel, waarna de problematische taken worden voltooid en de status wordt hersteld zonder dat het systeem hoeft te worden gestopt.
De nieuwe aanvalsmethode is gebaseerd op het afhandelen van "oops"-situaties , die kunnen leiden tot een verhoging van de waarde van de referentieteller (refcount), wat op zijn beurt kan resulteren in een overloop van de teller en het vrijgeven van het geheugen dat aan de refcount is gekoppeld.
In dit geval wordt de uitbuiting gereduceerd tot manipulaties die typerend zijn voor use-after-free-aanvallen (er doet zich een situatie voor waarin de referentietelling van het object nul wordt, het geheugen wordt vrijgegeven, maar er zijn in feite werkende koppelingen die verwijzen naar vrijgemaakt geheugen).
Momenteel genereert de Linux-kernel een oops wanneer deze een null-dereferentie vanuit een procescontext triggert. Dit is iets anders dan een kernelpanic. Een panic treedt op wanneer de kernel vaststelt dat er geen veilige manier is om de uitvoering voort te zetten en daarom alle uitvoering moet stoppen. Bij een oops stopt de kernel echter niet alle uitvoering; in plaats daarvan probeert de kernel zo goed mogelijk te herstellen en de uitvoering voort te zetten.
Het verwijderen van verwijzingen naar een NULL-pointer wordt hier gebruikt als een manier om de "oeps"-status op een gecontroleerde manier te genereren. Het probleem is dat er ongeveer 232 "oeps"-statusoproepen nodig zijn om een ​​32-bits refcount-overflow te bereiken.
In de praktijk duurt het ongeveer acht dagen van het continu genereren van out-of-place (OOP) toestanden om een ​​aanval uit te voeren met behulp van de voorgestelde exploit. Indien succesvol, stelt de exploit je in staat om je code op kernelniveau uit te voeren.
De NULL pointer-dereferentie die in de exploit werd gebruikt, werd in oktober verholpen, maar aangezien soortgelijke problemen niet ongewoon zijn en eerder werden behandeld als bugs, niet als kwetsbaarheden, zullen de ontwikkelaars algemene bescherming aan de Linux-kernel toevoegen om aanvallen te voorkomen die het genereren van "oeps" manipuleren. ."
In het geval van een taak betekent dat het weggooien van de bestaande kernelstack en direct naar make_task_dead gaan, dat do_exit aanroept. De kernel zal ook een "crash"-logboek naar dmesg posten en een kerneltracering die laat zien in welke staat de kernel verkeerde toen de fout optrad. Dit lijkt misschien een vreemde keuze wanneer geheugenbeschadiging duidelijk is opgetreden; het is echter de bedoeling om kernelbugs gemakkelijker te detecteren en te loggen onder de filosofie dat een werkend systeem veel gemakkelijker te debuggen is dan een systeem dat niet werkt.
Kernel 6.2 bevat met name wijzigingen om het maximale aantal "oops" te beperken . Nadat de limiet is bereikt, die standaard is ingesteld op 10 oops (dit kan desgewenst worden gewijzigd met de parameter oops_limit), zal de kernel overgaan naar een "panic"-status, gevolgd door een herstart. Hierdoor wordt het aantal iteraties dat nodig is om de referentieteller op nul te zetten, niet toegestaan.
Het is ook de bedoeling dat de beperking wordt overgedragen naar eerder uitgebrachte, maar nog steeds ondersteunde kerneltakken, evenals kernelpakketten van populaire distributies.
Als u hier meer over wilt weten , kunt u de details vinden via de volgende link.