For et par dage siden blev nyheden frigivet, som efterforskningsholdet af Qualys opdagede en denial of service-sårbarhed på grund af stakudmattelse i systemd, så enhver ikke-privilegeret bruger kan udnytte denne sårbarhed at blokere systemd.
Sårbarhed allerede katalogiseret som (CVE-2021-33910) Det nævnes, at det påvirker systemd er forårsaget af en fejl, når man forsøger at montere en mappe med en sti størrelse større end 8 MB gennem FUSE, og hvor kontrolinitialiseringsprocessen (PID1) løber tør for stakhukommelse og låses op og sætter system i en "panik" tilstand.
Denne sårbarhed blev introduceret i systemd v220 (apr. 2015) ved at forpligte 7410616c ("kernel: rework unit name manipulation and validation logic"), der erstattede en strdup () på bunken med en strdupa () i batteriet. Vellykket udnyttelse af denne sårbarhed tillader enhver uprivilegeret bruger at forårsage denial of service gennem kernepanik.
Så snart Qualys-forskergruppen bekræftede sårbarheden, deltog Qualys i ansvarlig afsløring af sårbarheden og koordinerede med forfatteren og distributioner af open source for at annoncere sårbarheden.
Forskerne nævner det problemet relateret til CVE-2021-33910 opstår på grund af det faktum, at systemd overvåger og analyserer indholdet af / proc / self / mountinfo og det håndterer hvert monteringspunkt i unit_name_path_escape () -funktionen, som får en operation kaldet "strdupa ()" til at blive udført, som sørger for at allokere dataene på stakken i stedet for bunken.
Det er derfor siden maksimalt tilladte stakstørrelse er begrænset ved hjælp af "RLIMIT_STACK" -funktionen, håndtering af for lang sti til monteringspunktet får "PID1" -processen til at hænge hvilket fører til, at systemet stopper.
Desuden nævner de, at for at et angreb skal fungere, kan det enkleste FUSE-modul bruges i kombination med brugen af et meget indlejret bibliotek som et monteringspunkt, hvis størrelse overstiger 8 MB.
også Det er vigtigt at nævne, at Qualys-forskerne nævne en bestemt sag med sårbarhed, siden især med systemd version 248 er udnyttelsen ikke funktionel på grund af en fejl, der er til stede i systemd-koden, der får / proc / self / mountinfo til at mislykkes. Det er også interessant, at der opstod en meget lignende situation i 2018, som når man forsøgte at skrive en udnyttelse af CVE-2018-14634 sårbarheden i Linux-kernen, hvor Qualys-forskere fandt tre andre kritiske sårbarheder i systemd.
Om sårbarhed Red Hat-teamet nævnte ethvert produkt, der er RHEL-kompatibelt, vil også potentielt blive påvirket.
Dette inkluderer:
- Produktcontainere, der er baseret på RHEL- eller UBI-containerbilleder. Disse billeder opdateres regelmæssigt, og containerstatus, der angiver, om der er en løsning på denne fejl, kan ses i Container Health Index, en del af Red Hat Container Catalog (https://access.redhat.com/containers) .
- Produkter, der trækker pakker fra RHEL-kanalen. Sørg for, at den underliggende Red Hat Enterprise Linux-systempakke er opdateret i disse produktmiljøer.
På grund af bredden af angrebsoverfladen af denne sårbarhed, Qualys anbefaler brugere at anvende de relevante programrettelser (som allerede blev frigivet for et par dage siden) for denne sårbarhed med det samme.
Som allerede nævnt er problemet dukket op siden systemd 220 (Apr 2015) og er allerede rettet i hovedopbevaringsstedet for systemd og er blevet rettet på de fleste distributioner Linux main samt dets derivater kan du kontrollere status i følgende links (Debian, Ubuntu, Fedora, RHEL, SUSE, Arch).
Endelig hvis du er interesseret i at vide mere om det om denne sårbarhed, kan du kontrollere detaljerne i den I det følgende link.