För några dagar sedan släpptes nyheten att utredningsgruppen för Qualys upptäckte en sårbarhet mot denial of service på grund av stackens utmattning i systemd, så att alla icke-privilegierade användare kan utnyttja denna sårbarhet att blockera systemd.
Sårbarhet redan katalogiserad som (CVE-2021-33910) Det nämns att det påverkar systemd orsakas av ett fel när man försöker montera en katalog med en sökvägstorlek som är större än 8 MB genom FUSE och där kontrollinitialiseringsprocessen (PID1) tar slut på stackminnet och låses upp, vilket sätter systemet i "panik" tillstånd.
Denna sårbarhet introducerades i systemd v220 (apr 2015) av commit 7410616c ("kernel: manipulation and validation logic of rework unit name"), som ersatte en strdup () på högen med en strdupa () i batteriet. Ett framgångsrikt utnyttjande av den här sårbarheten gör att alla icke -privilegierade användare kan orsaka denial of service genom kärnpanik.
Så snart Qualys forskargrupp bekräftade sårbarheten deltog Qualys i ansvarsfullt avslöjande av sårbarheten och samordnade med författaren och distributioner med öppen källkod för att meddela sårbarheten.
Det nämner forskarna problemet relaterad till CVE-2021-33910 uppstår på grund av att systemd övervakar och analyserar innehållet i / proc / self / mountinfo och den hanterar varje monteringspunkt i unit_name_path_escape () -funktionen som gör att en operation som kallas "strdupa ()" utförs som tar hand om allokeringen av data på stacken istället för högen.
Det är därför som sedan den högsta tillåtna stackstorleken är begränsad med funktionen "RLIMIT_STACK", hantering av för lång väg till monteringspunkten gör att "PID1" -processen hänger vilket leder till att systemet stannar.
Dessutom nämner de att för att en attack ska fungera kan den enklaste FUSE -modulen användas i kombination med användningen av en högkapslad katalog som en monteringspunkt, vars vägstorlek överstiger 8 MB.
Tambien Det är viktigt att nämna att Qualys forskare nämna ett särskilt fall med sårbarhet, sedan särskilt med systemd version 248 är exploateringen inte funktionell på grund av en bugg som finns i systemkoden som orsakar / proc / self / mountinfo att misslyckas. Det är också intressant att en mycket liknande situation uppstod under 2018, som när man försökte skriva en exploatering för CVE-2018-14634-sårbarheten i Linux-kärnan, där Qualys forskare hittade tre andra kritiska sårbarheter i systemd.
Om sårbarhet Red Hat -teamet nämnde alla produkter som är RHEL -kompatibla påverkas också potentiellt.
Detta inkluderar:
- Produktbehållare som är baserade på RHEL- eller UBI -containerbilder. Dessa bilder uppdateras regelbundet och behållarstatus som anger om det finns en korrigering för detta fel kan ses i Container Health Index, en del av Red Hat Container Catalog (https://access.redhat.com/containers) .
- Produkter som hämtar paket från RHEL -kanalen. Se till att det underliggande Red Hat Enterprise Linux systemd -paketet är uppdaterat i dessa produktmiljöer.
På grund av bredden på attackytan på denna sårbarhet, Qualys rekommenderar användare att använda lämpliga patchar (som redan släpptes för några dagar sedan) för denna sårbarhet omedelbart.
Som redan nämnts har problemet dykt upp sedan systemd 220 (apr 2015) och har redan fixats i huvudförvaret för systemd och har fixats på de flesta distributioner Linux main, liksom dess derivat, kan du kontrollera statusen i följande länkar (Debian, ubuntu, fedora, RHEL, SUSE, Arch).
Slutligen, om du är intresserad av att veta mer om det om denna sårbarhet kan du kontrollera detaljerna i den I följande länk.