10
Een paar dagen geleden kwam het nieuws naar buiten dat Er zijn twee kwetsbaarheden geïdentificeerd in de Linux-kernel de eerste was al gecatalogiseerd als CVE-2022-0435 en werd gevonden in de Linux-kernelmodule die zorgt voor de werking van het TIPC-netwerkprotocol (Transparent Inter-Process Communication).
Deze kwetsbaarheid zou kunnen toestaan dat code op kernelniveau wordt uitgevoerd door een pakket naar een speciaal ontworpen netwerk te sturen.
Het probleem beïnvloedt alleen systemen met de tipc.ko kernelmodule geladen en geconfigureerd met de TIPC-stack, die meestal wordt gebruikt in clusters en niet standaard is ingeschakeld op niet-gespecialiseerde Linux-distributies.
Kwetsbaarheid het wordt veroorzaakt door een stapeloverloop die optreedt bij het verwerken van pakketten, de waarde van het veld met het aantal lidknooppunten van het domein waarin het groter is dan 64.
Om de parameters van de knooppunten in de tipc.ko-module op te slaan, stelt een array "u32 members[64 ]" in, maar tijdens het verwerken van wat in het pakket is gespecificeerd. Het knooppuntnummer controleert niet de "member_cnt" -waarde, waardoor waarden groter dan 64 kunnen worden gebruikt voor het gecontroleerd overschrijven van gegevens in het onderstaande geheugengebied. de stapel na de "dom_bef" structuur.
Het TIPC-protocol is oorspronkelijk ontwikkeld door Ericsson, het is ontworpen om de communicatie tussen processen in een cluster te organiseren en wordt voornamelijk geactiveerd op de knooppunten van het cluster. TIPC kan zowel via Ethernet als UDP (netwerkpoort 6118) werken.
Bij het werken via Ethernet kan een aanval plaatsvinden vanaf het lokale netwerk, en bij gebruik van UDP vanaf het wereldwijde netwerk, als de poort niet wordt afgedekt door een firewall. De aanval kan ook worden uitgevoerd door een lokale gebruiker zonder privileges op de host. Om TIPC in te schakelen, moet u de tipc.ko-kernelmodule laden en binding aan een netwerkinterface configureren met behulp van netlink of het tipc-hulpprogramma.
Er wordt gezegd dat bij het bouwen van de kernel in "CONFIG_FORTIFY_SRC=y" modus (gebruikt in RHEL), die extra grenscontroles toevoegt aan de memcpy()-functie, de werking is beperkt tot een noodstop (kernel gaat naar de status "Kernel Panic").
Als het wordt uitgevoerd zonder aanvullende controles en informatie over de canarische vlaggen die worden gebruikt om de stapel te beschermen, is gelekt, kan het probleem worden gebruikt om op afstand code uit te voeren met kernelrechten. De onderzoekers die het probleem hebben geïdentificeerd, zeggen dat de exploit-techniek triviaal is en zal worden onthuld na de wijdverbreide verwijdering van de kwetsbaarheid in distributies.
De bug die de kwetsbaarheid heeft veroorzaakt, is geïntroduceerd op 15 juni 2016 en werd onderdeel van de Linux 4.8-kernel. kwetsbaarheid opgelost in kernelversies Linux 5.16.9, 5.15.23, 5.10.100, 5.4.179, 4.19.229, 4.14.266 en 4.9.301.
Nog een kwetsbaarheid die werd gevonden in de Linux-kernel is CVE-2022-24122 in de code om rlimit-beperkingen aan te pakken in verschillende gebruikersnaamruimten.
De bug is geïntroduceerd in een wijziging die is toegevoegd in de zomer van 2021, de implementatie van sommige RLIMIT-tellers verplaatsen om de "ucounts" -structuur te gebruiken. De "ucounts"-objecten die voor RLIMIT zijn gemaakt, bleven in gebruik nadat het geheugen dat eraan was toegewezen (use-after-free) was vrijgemaakt door de bijbehorende naamruimte te verwijderen, waardoor het mogelijk werd om hun code op kernelniveau uit te voeren.
Exploitatie van het beveiligingslek door een onbevoegde gebruiker is alleen mogelijk als het systeem onbevoegde toegang heeft tot de gebruikersidentificatienaamruimte (onbevoorrechte gebruikersnaamruimte), die standaard is ingeschakeld in Ubuntu en Fedora. , maar niet is ingeschakeld op Debian en RHEL.
Als tijdelijke oplossing om het beveiligingslek te blokkeren, kunt u onbevoegde toegang tot de naamruimte van de gebruiker uitschakelen:
sysctl -w kernel.unprivileged_userns_clone=0
Het probleem bestaat al sinds Linux kernel 5.14 en wordt opgelost in de 5.16.5- en 5.15.19-updates. De stabiele takken van Debian, Ubuntu, SUSE/openSUSE en RHEL worden niet beïnvloed door het probleem, maar verschijnen in nieuwe Fedora- en Arch Linux-kernels.