onlangs Qualys beveiligingsonderzoekers (een bedrijf voor cloudbeveiliging, compliance en aanverwante diensten) vrijgegeven details van een kwetsbaarheid wat ze hebben gedetecteerd en wat? ze beïnvloeden de Linux-kernel.
CVE-2021-33909 beïnvloedt de kernel en stelt een lokale gebruiker in staat om code-uitvoering te bereiken en escaleer privileges door zeer geneste mappen te manipuleren.
De kwetsbaarheid is te wijten aan het gebrek aan validatie van het resultaat van het converteren van size_t naar het type int voordat u bewerkingen uitvoert op de seq_file-code, die bestanden maakt van een reeks records. Gebrek aan validatie kan resulteren in schrijfbewerkingen naar een gebied buiten de bufferlimieten bij het maken, koppelen en verwijderen van een directorystructuur met een zeer hoog niveau van nesting (padgrootte groter dan 1 GB).
Elke niet-bevoorrechte gebruiker kan rootrechten krijgen op een kwetsbare host door dit beveiligingslek in een standaardconfiguratie te misbruiken.
Als gevolg hiervan kan een aanvaller een tekenreeks van 10 bytes krijgen "// verwijderd" met een offset van "- 2 GB - 10 bytes", wijzend naar het gebied direct voor de toegewezen buffer.
De dreiging van kwetsbaarheid wordt verergerd door het feit dat: onderzoekers waren in staat om functionele exploits voor te bereiden op Ubuntu 20.04, Debian 11 en Fedora 34 in de standaardinstellingen. Opgemerkt wordt dat andere distributies niet zijn getest, maar theoretisch zijn ze ook vatbaar voor het probleem en kunnen ze worden aangevallen.
Succesvol misbruik van dit beveiligingslek stelt elke onbevoegde gebruiker in staat rootrechten te verkrijgen op de kwetsbare host. De beveiligingsonderzoekers van Qualys zijn in staat geweest om de kwetsbaarheid onafhankelijk te verifiëren, een exploit te ontwikkelen en volledige rootrechten te verkrijgen op standaardinstallaties van Ubuntu 20.04, Ubuntu 20.10, Ubuntu 21.04, Debian 11 en Fedora 34 Workstation. Andere Linux-distributies zijn waarschijnlijk kwetsbaar en waarschijnlijk exploiteerbaar.
Het werk van de exploit komt neer op het creëren van een hiërarchie van ongeveer een miljoen mappen genest via mkdir () oproep om een bestandspad groter dan 1 GB te bereiken.
Deze directory wordt aan een bind-mount gekoppeld in een aparte gebruikersnaamruimte, waarna de functie rmdir () wordt uitgevoerd om deze te verwijderen. Tegelijkertijd wordt een thread gemaakt die een klein eBPF-programma laadt, dat in het stadium blijft hangen na het verifiëren van de eBPF-pseudocode, maar vóór de JIT-compilatie ervan.
In de niet-geprivilegieerde gebruikers-ID-naamruimte wordt het bestand / proc / self / mountinfo geopend en wordt het lange mappad gelezen dat is gekoppeld met bind-mount, wat ertoe leidt dat de regel "// delete" wordt geschreven in de regio vóór het begin van de buffer. De positie voor het schrijven van de regel is zo gekozen dat deze de instructie in het reeds geteste maar nog niet gecompileerde eBPF-programma overschrijft.
Bovendien, op het niveau van het eBPF-programma, ongecontroleerd wegschrijven uit de buffer wordt omgezet in een lees-/schrijfmogelijkheid gecontroleerd in andere kernelstructuren door de btf- en map_push_elem-structuren te manipuleren.
De exploit plaatst vervolgens de modprobe_path []-buffer in het kernelgeheugen en overschrijft het pad "/sbin / modprobe" daarin, waardoor elk uitvoerbaar bestand als root kan worden gestart als een request_module ()-aanroep wordt gedaan, die bijvoorbeeld wordt uitgevoerd bij het maken een netlink-socket...
Onderzoekers hebben verschillende oplossingen geboden die alleen effectief zijn voor een specifieke exploit, maar ze lossen het probleem zelf niet op.
Daarom wordt aanbevolen om de parameter "/ proc / sys / kernel / unprivileged_userns_clone" in te stellen op 0 om het aankoppelen van mappen in een aparte gebruikersnaamruimte uit te schakelen en "/ proc sys / kernel / unprivileged_bpf_disabled" op 1 om het laden van eBPF-programma's uit te schakelen in de kern.
Naast het feit dat alle gebruikers van een Linux-distributie ook worden aanbevolen om hun systeem bij te werken om de bijbehorende patch te hebben. Het probleem is duidelijk sinds juli 2014 en het beïnvloedt kernelversies sinds 3.16. De kwetsbaarheidspatch is gecoördineerd met de gemeenschap en op 19 juli in de kernel geaccepteerd.
Tot slot, als u er meer over wilt weten, kunt u de details in de volgende link.