Acum câteva zile a fost lansată știrea că echipa de anchetă a Qualys a descoperit o vulnerabilitate a refuzului de serviciu datorită epuizării stivei în systemd, astfel încât orice utilizator neprivilegiat poate exploata această vulnerabilitate a bloca systemd.
Vulnerabilitate deja catalogat ca (CVE-2021-33910) Este menționat faptul că afectează systemd este cauzat de un eșec atunci când se încearcă montarea unui director cu o dimensiune a căii mai mare de 8 MB prin FUSE și în care procesul de inițializare a controlului (PID1) rămâne fără memorie stivă și se blochează, punând sistem în stare de „panică”.
Această vulnerabilitate a fost introdusă în systemd v220 (aprilie 2015) de commit 7410616c („kernel: rework work name manipulation and validation logic”), care a înlocuit un strdup () pe heap cu un strdupa () în baterie. Exploatarea cu succes a acestei vulnerabilități permite oricărui utilizator neprivilegiat să provoace refuzul de serviciu prin panica kernelului.
De îndată ce echipa de cercetare Qualys a confirmat vulnerabilitatea, Qualys a participat la dezvăluirea responsabilă a vulnerabilității și a coordonat cu autorul și distribuțiile open source pentru a anunța vulnerabilitatea.
Cercetătorii menționează că problema legat de CVE-2021-33910 apare din cauza faptului că systemd monitorizează și analizează conținutul din / proc / self / mountinfo și gestionează fiecare punct de montare în funcția unit_name_path_escape () care determină executarea unei operații numite "strdupa ()" care se ocupă de alocarea datelor pe stivă în loc de heap.
De aceea de atunci dimensiunea maximă admisă a stivei este limitată prin funcția „RLIMIT_STACK”, gestionarea unei căi prea lungi până la punctul de montare determină blocarea procesului „PID1” ceea ce duce la oprirea sistemului.
În plus, menționează că pentru ca un atac să fie funcțional, cel mai simplu modul FUSE poate fi utilizat în combinație cu utilizarea unui director foarte imbricat ca punct de montare, a cărui dimensiune a căii depășește 8 MB.
también Este important să menționăm că cercetătorii Qualys menționează un caz particular cu vulnerabilitate, din moment ce mai ales cu sistemd versiunea 248, exploit-ul nu este funcțional datorită unei erori care este prezentă în codul systemd care face ca / proc / self / mountinfo să eșueze. De asemenea, este interesant că o situație foarte similară a apărut în 2018, deoarece în timp ce încercam să scriem un exploit pentru vulnerabilitatea CVE-2018-14634 în nucleul Linux, în care cercetătorii Qualys au găsit alte trei vulnerabilități critice în systemd.
Despre vulnerabilitate Echipa Red Hat a menționat orice produs care este conform RHEL va fi, de asemenea, potențial afectat.
Aceasta include:
- Containere de produse care se bazează pe imagini de containere RHEL sau UBI. Aceste imagini sunt actualizate în mod regulat, iar starea containerului care indică dacă este disponibilă o remediere pentru acest defect poate fi vizualizată în Container Health Index, parte a catalogului Red Hat Container (https://access.redhat.com/containers) .
- Produse care extrag pachete de pe canalul RHEL. Asigurați-vă că pachetul sistem de bază Red Hat Enterprise Linux este actualizat în aceste medii de produse.
Datorită lățimii suprafeței de atac a acestei vulnerabilități, Qualys recomandă utilizatorilor să aplice patch-urile corespunzătoare (care au fost deja lansate acum câteva zile) pentru această vulnerabilitate imediat.
După cum sa menționat deja, problema a apărut de la systemd 220 (aprilie 2015) și a fost deja reparat în principalul depozit al systemd și a fost fixat pe majoritatea distribuțiilor Linux principal, precum și derivatele sale, puteți verifica starea în următoarele link-uri (Debian, Ubuntu, Fedora, RHEL, SUSE, Arc).
În cele din urmă, dacă sunteți interesat să aflați mai multe despre asta despre această vulnerabilitate, puteți verifica detaliile acesteia În următorul link.