Fa alguns dies es va donar a conèixer la notícia que l'equip de recerca de Qualys va descobrir una vulnerabilitat de denegació de servei per esgotament de la pila en systemd, de manera que qualsevol usuari sense privilegis pot aprofitar aquesta vulnerabilitat per bloquejar systemd.
la vulnerabilitat ja catalogada com (CVE-2021-33910) s'esmenta que afecta a systemd és causada per una fallada en intentar muntar un directori amb una mida de ruta superior a 8 MB a través de FUSE i en què el procés d'inicialització del control (PID1) es queda sense memòria de pila i es bloqueja, cosa que posa el sistema en un estat de «pànic».
Aquesta vulnerabilitat es va introduir en systemd v220 (abril de 2015) mitjançant el compromís 7410616c («nucli: lògica de validació i manipulació del nom de la unitat de reelaboració»), que va reemplaçar un strdup () al munt per un strdupa () a la pila. L'explotació d'aquesta vulnerabilitat permet que qualsevol usuari sense privilegis provoqui la denegació de servei a través del pànic del nucli.
Tan bon punt l'equip de recerca de Qualys va confirmar la vulnerabilitat, Qualys va participar en la divulgació responsable de la vulnerabilitat i es va coordinar amb l'autor i les distribucions de codi obert per anunciar la vulnerabilitat.
Els investigadors esmenten que el problema relacionat amb CVE-2021-33910 sorgeix a causa del fet que systemd monitoritza i analitza el contingut de /proc/self/mountinfo i maneja cada punt de muntatge a la funció unit_name_path_escape() el que fa que s'executi una operació anomenada «strdupa()» la qual s'encarrega d'assignar les dades a la pila en lloc de al munt.
És per això que atès que la mida màxima permesa de pila està limitada per la funció RLIMIT_STACK, manejar una ruta massa llarga al punt de muntatge fa que es bloci el procés «PID1» cosa que fa que s'aturi el sistema.
A més, esmenten que perquè un atac sigui funcional, es pot fer servir el mòdul FUSE més simple en combinació amb l'ús d'un directori altament imbricat com a punt de muntatge, la mida de ruta del qual excedeix els 8 MB.
també és important esmentar que els investigadors de Qualys fan esment sobre un cas en particular amb la vulnerabilitat, ja que especialment amb la versió de systemd 248, l'exploit no és funcional degut a que un error que està present al codi de systemd que fa que /proc/self/mountinfo falli. També és interessant que el 2018 va sorgir una situació molt similar, ja que mentre intentaven escriure un exploit per a la vulnerabilitat CVE-2018-14634 al nucli de Linux, en el qual els investigadors de Qualys van trobar tres vulnerabilitats crítiques més en systemd.
Sobre la vulnerabilitat l'equip de Red Hat esmento que qualsevol producte que sigui compatible amb RHEL també es veurà potencialment afectat.
Això inclou:
- Contenidors de productes que es basen en les imatges de contenidors RHEL o UBI. Aquestes imatges s'actualitzen amb regularitat, i l'estat del contenidor que indica si hi ha una solució disponible per a aquesta falla es pot veure a Container Health Index, part del Red Hat Container Catalog (https://access.redhat.com/containers).
- Productes que extreuen paquets del canal RHEL. Assegureu-vos que el paquet systemd subjacent de Red Hat Enterprise Linux estigui actualitzat en aquests entorns de productes.
A causa de l'amplitud de la superfície d'atac d'aquesta vulnerabilitat, Qualys recomana als usuaris que apliquin els pegats corresponents (que ja van ser alliberats fa pocs dies) per a aquesta vulnerabilitat immediatament.
Com ja es va esmentar el problema ha aparegut des de systemd 220 (abril de 2015) i ja s'ha solucionat a el repositori principal de systemd i s'ha solucionat a la majoria de les distribucions de Linux principals, així com també en els seus derivats, poden consultar l'estatus als següents enllaços (Debian, Ubuntu, Fedora, RHEL, SUSE, Arc).
Finalment, si estàs interessat en poder conèixer més a l'respecte sobre aquesta vulnerabilitat, en pots consultar els detalls en el següent enllaç.