For noen dager siden ble nyheten utgitt som etterforskningsteamet til Qualys oppdaget et sårbarhetsproblem på grunn av utmattelse av stack i systemd, slik at enhver ikke-privilegert bruker kan utnytte dette sikkerhetsproblemet å blokkere systemd.
Sårbarhet allerede katalogisert som (CVE-2021-33910) Det nevnes at det påvirker systemd er forårsaket av en feil når du prøver å montere en katalog med en banestørrelse større enn 8 MB gjennom FUSE og der kontrollinitialiseringsprosessen (PID1) går tom for stakkminne og låses opp, og setter systemet i en "panikk" tilstand.
Dette sikkerhetsproblemet ble introdusert i systemd v220 (april 2015) av commit 7410616c ("kjerne: manipulering og validering av logikk for enhetsnavn), som erstattet en strdup () på haugen med en strdupa () i batteriet. Vellykket utnyttelse av dette sikkerhetsproblemet gjør at enhver uprivileggert bruker kan forårsake tjenestenekt gjennom kjernepanikk.
Så snart Qualys forskningsteam bekreftet sårbarheten, deltok Qualys i ansvarlig avsløring av sårbarheten og koordinerte med forfatteren og distribusjoner med åpen kildekode for å kunngjøre sårbarheten.
Forskerne nevner det problemet knyttet til CVE-2021-33910 oppstår på grunn av det faktum at systemd overvåker og analyserer innholdet i / proc / self / mountinfo og den håndterer hvert monteringspunkt i unit_name_path_escape () -funksjonen som får en operasjon kalt "strdupa ()" til å bli utført som tar seg av å tildele dataene på stabelen i stedet for haugen.
Det er derfor siden maksimal tillatt stabelstørrelse er begrenset av "RLIMIT_STACK" -funksjonen, Håndtering av for lang bane til festepunktet får "PID1" -prosessen til å henge noe som fører til at systemet stopper.
I tillegg nevner de at for et angrep for å være funksjonelt, kan den enkleste FUSE -modulen brukes i kombinasjon med bruk av en høyt nestet katalog som et monteringspunkt, hvis banestørrelse overstiger 8 MB.
også Det er viktig å nevne at Qualys -forskerne nevne en bestemt sak med sårbarhet, siden spesielt med systemd versjon 248 er utnyttelsen ikke funksjonell på grunn av en feil som er tilstede i systemd -koden som får / proc / self / mountinfo til å mislykkes. Det er også interessant at det oppstod en veldig lignende situasjon i 2018, mens du prøvde å skrive en utnyttelse av CVE-2018-14634-sårbarheten i Linux-kjernen, der Qualys-forskere fant tre andre kritiske sårbarheter i systemd.
Om sårbarhet Red Hat -teamet nevnte ethvert produkt som er RHEL -kompatibelt, vil også potensielt bli påvirket.
Dette inkluderer:
- Produktbeholdere som er basert på RHEL- eller UBI -containerbilder. Disse bildene oppdateres regelmessig, og beholderstatusen som indikerer om en løsning er tilgjengelig for denne feilen, kan ses i Container Health Index, en del av Red Hat Container Catalog (https://access.redhat.com/containers) .
- Produkter som henter pakker fra RHEL -kanalen. Sørg for at den underliggende Red Hat Enterprise Linux systemd -pakken er oppdatert i disse produktmiljøene.
På grunn av bredden på angrepsflaten til denne sårbarheten, Qualys anbefaler brukere å bruke de riktige oppdateringene (som allerede ble utgitt for noen dager siden) for dette sikkerhetsproblemet umiddelbart.
Som allerede nevnt har problemet dukket opp siden systemd 220 (apr 2015) og er allerede fikset hovedlageret til systemd og har blitt løst på de fleste distribusjoner Linux main, så vel som dets derivater, kan du sjekke statusen i følgende lenker (Debian, Ubuntu, Fedora, RHEL, SUSE, Arch).
Endelig, hvis du er interessert i å vite mer om det om dette sikkerhetsproblemet, kan du sjekke detaljene i det I den følgende lenken.