Utgivelse av LKRG 0.8-modulen for å beskytte mot utnyttelse av sårbarheter i Linux-kjernen

Openwall-prosjekt publisert utgivelse av kjernemodul LKRG 0.8 (Linux Kernel Runtime Guard), designet for å oppdage og blokkere angrep og brudd på integriteten til kjernestrukturer. Modulen kan for eksempel beskytte mot uautoriserte endringer i den kjørende kjernen og forsøk på å endre tillatelsene til brukerprosesser (oppdage bruk av utnyttelser). Modulen egner seg både for å organisere beskyttelse mot allerede kjente utnyttelser for Linux-kjernen (for eksempel i situasjoner der det er vanskelig å oppdatere kjernen i systemet), og for å motvirke utnyttelser for ennå ukjente sårbarheter. Prosjektkode distribuert av lisensiert under GPLv2.

Blant endringene i den nye versjonen:

  • Plasseringen av LKRG-prosjektet er endret, som ikke lenger er delt inn i separate delsystemer for kontroll av integritet og bestemmelse av bruk av utnyttelser, men presenteres som et komplett produkt for å identifisere angrep og ulike integritetsbrudd;
  • Kompatibilitet er gitt med Linux-kjerner fra 5.3 til 5.7, så vel som med kjerner kompilert med aggressive GCC-optimaliseringer, uten CONFIG_USB- og CONFIG_STACKTRACE-alternativene eller med CONFIG_UNWINDER_ORC-alternativet, samt med kjerner som ikke har LKRG-tilkoblede funksjoner, hvis de kan unnlates;
  • Når du bygger, blir noen obligatoriske CONFIG_* kjerneinnstillinger sjekket for å generere meningsfulle feilmeldinger i stedet for obskure krasj;
  • Lagt til støtte for standby (ACPI S3, suspend til RAM) og hvilemodus (S4, suspend til disk) moduser;
  • Lagt til DKMS-støtte til Makefile;
  • Eksperimentell støtte for 32-biters ARM-plattformer er implementert (testet på Raspberry Pi 3 Model B). Tidligere tilgjengelig støtte for AArch64 (ARM64) har blitt utvidet for å gi kompatibilitet med Raspberry Pi 4-kortet;
  • Nye kroker er lagt til, inkludert en kapabel() samtalebehandler for bedre å identifisere utnyttelser som manipulerer "evner", ikke prosess-ID-er (Legitimasjon);
  • Ny logikk er foreslått for å oppdage forsøk på å unnslippe navneromsbegrensninger (for eksempel fra Docker-beholdere);
  • På x86-64-systemer blir SMAP-biten (Supervisor Mode Access Prevention) sjekket og brukt, designet for å blokkere tilgang til brukerplassdata fra privilegert kode som kjører på kjernenivå. SMEP-beskyttelse (Supervisor Mode Execution Prevention) ble implementert tidligere;
  • Under drift plasseres LKRG-innstillingene på en minneside som vanligvis er skrivebeskyttet;
  • Logginformasjon som kan være mest nyttig for angrep (for eksempel informasjon om adresser i kjernen) er begrenset til feilsøkingsmodus (log_level=4 og høyere), som er deaktivert som standard.
  • Skalerbarheten til prosesssporingsdatabasen har blitt økt - i stedet for ett RB-tre beskyttet av en spinlock, brukes en hash-tabell med 512 RB-trær beskyttet av 512 lese-skrive-låser;
  • En modus er implementert og aktivert som standard, der integriteten til prosessidentifikatorer ofte sjekkes kun for gjeldende oppgave, og også valgfritt for aktiverte (våkne) oppgaver. For andre oppgaver som er i dvaletilstand eller fungerer uten tilgang til kjerne-APIet kontrollert av LKRG, utføres kontrollen sjeldnere.
  • Lagt til nye sysctl- og modulparametere for finjustering av LKRG, samt to sysctl for forenklet konfigurasjon ved å velge fra sett med finjusteringsinnstillinger (profiler) utarbeidet av utviklerne;
  • Standardinnstillingene er endret for å oppnå en mer balansert balanse mellom hastigheten på deteksjon av brudd og effektiviteten til responsen, på den ene siden, og innvirkningen på ytelsen og risikoen for falske positiver, på den andre;
  • Systemd-enhetsfilen har blitt redesignet for å laste LKRG-modulen tidlig under oppstart (et kommandolinjealternativ for kjerne kan brukes til å deaktivere modulen);

Tatt i betraktning optimaliseringene som er foreslått i den nye utgivelsen, er ytelsesreduksjonen ved bruk av LKRG 0.8 estimert til 2.5 % i standardmodus (“tung”) og 2 % i lett modus (“lett”).

I en nylig avholdt studie effektiviteten til pakker for å oppdage rootkits LKRG viste beste resultater, identifisering av 8 av 9 testede rootkits som fungerer på kjernenivå uten falske positiver (rootkits Diamorphine, Honey Pot Bears, LilyOfTheValley, Nuk3 Gh0st, Puszek, Reptile, Rootfoo Linux Rootkit og Sutekh ble identifisert, men Keysniffer, som er en kjerne modul, ble savnet med en keylogger, ikke et rootkit i bokstavelig forstand). Til sammenligning oppdaget AIDE-, OSSEC- og Rootkit Hunter-pakkene 2 av 9 rootkits, mens Chkrootkit ikke oppdaget noen. Samtidig støtter ikke LKRG gjenkjenning av rootkits plassert i brukerrommet, så størst effektivitet oppnås ved bruk av en kombinasjon av AIDE og LKRG, som gjorde det mulig å identifisere 14 av 15 rootkits av alle typer.

I tillegg kan det bemerkes at distribusjonsutvikleren Whonix jeg begynte dannelse ferdige pakker med DKMS for Debian, Whonix, Qubes og Kicksecure, og en pakke for Arch Linux allerede oppdatert til versjon 0.8. Pakker med LKRG er også tilgjengelig på russisk alt linux и AstraLinux.

Integritetskontroll i LKRG utføres ved å sammenligne den faktiske koden og dataene til kjernen og modulene, noen viktige datastrukturer og CPU-innstillinger med lagrede hashes eller kopier av tilsvarende minneområder, datastrukturer eller registre. Sjekker aktiveres både periodisk av timer og ved forekomst av ulike hendelser.

Bestemmelse av mulig bruk av utnyttelser og blokkering av angrep utføres på stadiet før kjernen gir tilgang til ressurser (for eksempel før åpning av en fil), men etter at prosessen har mottatt uautoriserte tillatelser (for eksempel endring av UID). Når uautorisert atferd oppdages, tvinges prosesser til å avsluttes som standard, noe som er tilstrekkelig til å blokkere mange utnyttelser.

Kilde: opennet.ru

Legg til en kommentar