Een paar dagen geleden kwam het nieuws naar buiten dat het onderzoeksteam van Qualys ontdekte een denial of service-kwetsbaarheid vanwege uitputting van de stapel in systemd, dus elke niet-bevoorrechte gebruiker kan misbruik maken van dit beveiligingslek systeem te blokkeren.
Kwetsbaarheid al gecatalogiseerd als (CVE-2021-33910) Er wordt vermeld dat het van invloed is op systemd wordt veroorzaakt door een fout bij het aankoppelen van een map met een padgrootte groter dan 8 MB via FUSE en waarin het besturingsinitialisatieproces (PID1) geen stapelgeheugen meer heeft en vastloopt, waardoor de systeem in een "paniek" staat.
Deze kwetsbaarheid is geïntroduceerd in systemd v220 (april 2015) door commit 7410616c ("kernel: herbewerkingseenheidsnaammanipulatie en validatielogica"), die een strdup () op de heap verving door een strdupa () in de batterij. Succesvol misbruik van dit beveiligingslek stelt elke onbevoegde gebruiker in staat om denial of service te veroorzaken door middel van kernel panic.
Zodra het onderzoeksteam van Qualys de kwetsbaarheid bevestigde, nam Qualys deel aan de verantwoorde onthulling van de kwetsbaarheid en coördineerde het met de auteur en open source-distributies om de kwetsbaarheid aan te kondigen.
De onderzoekers vermelden dat het probleem gerelateerd aan CVE-2021-33910 ontstaat vanwege het feit dat: systemd controleert en parseert de inhoud van / proc / self / mountinfo en het behandelt elk aankoppelpunt in de functie unit_name_path_escape () die ervoor zorgt dat een bewerking met de naam "strdupa ()" wordt uitgevoerd die ervoor zorgt dat de gegevens op de stapel worden toegewezen in plaats van op de heap.
Dat is de reden waarom sinds maximaal toegestane stapelgrootte is beperkt door de functie "RLIMIT_STACK", het hanteren van een te lang pad naar het aankoppelpunt zorgt ervoor dat het "PID1"-proces vastloopt waardoor het systeem stopt.
Bovendien vermelden ze dat om een aanval functioneel te laten zijn, de eenvoudigste FUSE-module kan worden gebruikt in combinatie met het gebruik van een sterk geneste map als koppelpunt, waarvan de padgrootte 8 MB overschrijdt.
ook Het is belangrijk om te vermelden dat de Qualys-onderzoekers een specifiek geval vermelden met kwetsbaarheid, aangezien vooral met systemd-versie 248 is de exploit niet functioneel vanwege een bug in de systemd-code die ervoor zorgt dat / proc / self / mountinfo niet werkt. Het is ook interessant dat zich in 2018 een zeer vergelijkbare situatie voordeed, toen we probeerden een exploit te schrijven voor de CVE-2018-14634-kwetsbaarheid in de Linux-kernel, waarin Qualys-onderzoekers drie andere kritieke kwetsbaarheden in systemd vonden.
Over kwetsbaarheid het Red Hat-team genoemd elk product dat RHEL-compatibel is, zal mogelijk ook worden beïnvloed.
Dit omvat:
- Productcontainers die zijn gebaseerd op RHEL- of UBI-containerafbeeldingen. Deze afbeeldingen worden regelmatig bijgewerkt en de containerstatus die aangeeft of er een oplossing beschikbaar is voor deze fout, kan worden bekeken in de Container Health Index, onderdeel van de Red Hat Container Catalog (https://access.redhat.com/containers) .
- Producten die pakketten uit het RHEL-kanaal halen. Zorg ervoor dat het onderliggende Red Hat Enterprise Linux systemd-pakket up-to-date is in deze productomgevingen.
Vanwege de omvang van het aanvalsoppervlak van deze kwetsbaarheid, Qualys raadt gebruikers aan de juiste patches toe te passen (die een paar dagen geleden al zijn vrijgegeven) voor dit beveiligingslek onmiddellijk.
Zoals eerder vermeld, is het probleem opgetreden sinds systemd 220 (april 2015) en is al gerepareerd de belangrijkste opslagplaats van systemd en is opgelost op de meeste distributies Linux main, evenals zijn afgeleiden, kunt u de status controleren in de volgende links (Debian, Ubuntu, Fedora, RHEL, SUS, boog).
Tenslotte als u er meer over wilt weten over deze kwetsbaarheid, kunt u de details ervan controleren In de volgende link.