Utnyttelse av nullreferanser i Linux-kjernen
Det ble nylig annonsert at forskere fra Google Project Zero-teamet har utviklet en metode for å utnytte sårbarheter i Linux-kjernen forårsaket av dereferansen til NULL-pekeren.
Kjerneproblemer knyttet til dereferansering av NULL-pekere har frem til nå ikke fått tilstrekkelig oppmerksomhet , da det ble ansett som urealistisk å gjøre slike problemer om til angrep som førte til privilegiumsøkning eller utførelse av ens egen kode ( det er forbudt å tilordne uprivilegerte prosesser til den nedre delen av adresserommet).
Som en generell regel fører slike feil til generering av oops-advarsler av kjernen, hvoretter de problematiske oppgavene fullføres og tilstanden gjenopprettes uten behov for å stoppe systemet.
Den nye angrepsmetoden er basert på håndtering av "oops"-tilstander , som kan resultere i en økning i verdien til referansetelleren (refcount), som igjen kan føre til at telleren overfylles og frigjør minnet som er knyttet til refcounten.
I dette tilfellet reduseres utnyttelsen til manipulasjoner som er typiske for bruk-etter-frie angrep (en situasjon oppstår der referanseantallet til objektet blir null, minne frigjøres, men faktisk er det fungerende lenker som peker til frigjort minne).
For tiden, når Linux-kjernen utløser en null-dereferanse fra en prosesskontekst, genererer den en oops , som er forskjellig fra en kernel panic. En panikk oppstår når kjernen bestemmer at det ikke finnes noen sikker måte å fortsette kjøringen på, og derfor må stoppe all kjøring. Kjernen stopper imidlertid ikke all kjøring under en oops; i stedet prøver kjernen å gjenopprette så godt den kan og fortsetter kjøringen.
Frareferanse til en NULL-peker brukes her som en måte å generere "oops"-tilstanden på en kontrollert måte. Problemet er at det tar omtrent 232 "oops"-statusanrop for å nå en 32-bits refcount-overflyt.
Fra et praktisk synspunkt tar det omtrent åtte dager med kontinuerlig generering av out-of-place (OOP)-tilstander å utføre et angrep med den foreslåtte utnyttelsen. Hvis den lykkes, lar utnyttelsen deg kjøre koden din på kjernenivå.
NULL-pekerreferansen som ble brukt i utnyttelsen ble fikset i oktober, men siden lignende problemer ikke er uvanlige og tidligere ble behandlet som feil, ikke sårbarheter, vil utviklerne legge til generell beskyttelse til Linux-kjernen for å forhindre angrep som manipulerer genereringen av "oops" ."
Når det gjelder en oppgave, betyr det å forkaste den eksisterende kjernestabelen og gå direkte til make_task_dead som kaller do_exit. Kjernen vil også legge ut til dmesg en "krasj"-logg og en kjernesporing som viser hvilken tilstand kjernen var i da feilen oppstod. Dette kan virke som et merkelig valg når minnekorrupsjon tydelig har oppstått; Men hensikten er å gjøre kjernefeil lettere å oppdage og logge under filosofien om at et kjørende system er mye lettere å feilsøke enn et nede.
Spesielt inkluderer Kernel 6.2 endringer for å begrense det maksimale antallet "oops" . Etter å ha nådd grensen, som er satt til 10 000 oops som standard (du kan endre dette ved hjelp av oops_limit-parameteren om ønskelig), vil kjernen starte en overgang til en "panikk"-tilstand, etterfulgt av en omstart, som ikke tillater antallet iterasjoner som kreves for å tilbakestille refcount til null.
Det er også planlagt at begrensningen skal overføres til tidligere utgitte, men fortsatt støttede kjernegrener, samt kjernepakker av populære distribusjoner.
Til slutt, hvis du er interessert i å lære mer om dette , kan du finne detaljene på følgende lenke.