Qualys waarschuwen voor een kwetsbaarheid in pkexec van Polkit. Dat programma komt in vrijwel alle Linux-distributies voor. Door het lek kan iemand zich voordoen alsof hij alle rechten heeft en vervolgens als rootgebruiker acties uitvoeren op een Linux-systeem. De onderzoekers van de informatiebeveiliger hebben geconstateerd dat die truc werkt.
Ze hebben de rechten van rootgebruiker kunnen krijgen bij standaardinstallaties van Ubuntu, Debian, Fedora en CentOS. Andere Linux-distributies zijn waarschijnlijk net zo kwetsbaar voor misbruik, meldt de beveiliger.
De specifieke kwetsbaarheid zit al vanaf het eerste begin in Linux-software en is gemakkelijk uit te buiten. Het onderzoeksteam van de informatiebeveiliger publiceert om die reden bewust geen technische beschrijving van de bug.
Log4Shell en Solarwinds
Benelux & Nordics-directeur van Qualys, Chantal ’t Gilde, noemt de melding een ‘wake-upcall’. ‘In dit tijdperk van Log4Shell, Solarwinds, MSFT Exchange, en ga zo maar door, is het essentieel dat kwetsbaarheden op verantwoorde wijze worden gemeld en ingeperkt.’ Daarmee verwijst ze naar eerdere omvangrijke lekken in veelgebruikte systemen.
Gezien de omvang van het risico dat deze bug met zich meebrengt voor zowel Linux- als niet-Linux-besturingssystemen, raadt Qualys gebruikers aan om onmiddellijk te patchen. In een blog is aanvullende informatie beschikbaar over de kwetsbaarheid in Linux.
Dat is geen nieuws, de patches zijn al uit. De melding was 2 dagen geleden al op andere media.
Zeker Jan maar zo’n zin als: “This vulnerability has been hiding in plain sight for 12+ years” geeft toch aan dat open source als de juridische voorwaarden van clouddiensten zijn omdat niemand de code leest ondanks dat deze voor iedereen leesbaar is. En ja, kwetsbaarheid was al enige maanden bekend maar er werd geen ruchtbaarheid aan gegeven zodat ontwikkelaars het lek met een patch konden dichten.
Of een ieder dat uiteindelijk ook doet is een eigen verantwoordelijkheid want aangaande de updateritis heb ik met Linux een avondtaak aan het up-to-date houden van alle software. En dat is natuurlijk geheel mijn eigen schuld want omdat het allemaal gratis is wil ik het ook allemaal hebben;-)
@oudlid
ik weet niet welke distro je hebt maar ik heb daar geen problemen. Wist je dat je updates ook in Linux autoamtisch kunt laten installeren?
Jan, oudlid doelt op updateritus. Je schreef er zelf over anderhalf jaar geleden. Dat ging over niet-zo-noodzakelijke updates, maar oudlid veegt de boel bij elkaar om er dan overheen.. nou ja laat maar.
Vaak zijn inderdaad niet de individuele packages het probleem, maar dependencies binnen de hele stack.
Containers kunnen oplossing vormen, maar das nog niet zo makkelijk. Veel zelf uitzoeken, waaronder de persistent storage en backup/restore. Of zoals RedHat deed met AWX, de upstream van Tower, dat de volgende release ineens binnen een heel container orchestration systeem moeit draaien ipv gewoon met docker/podman.
Voordeel van niet delen van een database engine of Java versie is dat je die gewoon kunt upgraden zonder andere applicaties te raken. Echter ook hier geldt, dat hoewel updaten simpel is, het daarna weer te laten werken soms lastiger.
Maar bij oudlid is het trouwens blijkbaar allemaal zijn eigen schuld 😉
Inderdaad bedoel ik de update frequentie want zoals Dino al zegt gaat het niet om de simpelheid van updaten maar om het werkend houden van een oplossing. En een puntoplossing is inderdaad wat anders dan een keten aan afhankelijkheden waarin ik beveiligingsupdates toch wat anders beoordeel dan niet-noodzakelijk. Nu is natuurlijk niet elke beveiligingsupdate urgent want als er al 12+ jaar geen bloed uit is gevloeid dan is nog eens 12 jaar niks doen een weloverwogen risico. De eigen verantwoordelijkheid blijft dan ook een probleem want het patch management is binnen het risico management op de dichterlijke wijze van Dino als een (_!_) in een netje zolang de shit de fan niet raakt omdat de business beveiling minder noodzakelijk vindt dan functionaliteit.
Verder vinden we aangaande een onsje meer worst lekker maar willen we niet weten hoe de worst gemaakt wordt want wat betreft het op een hoop gooien is het dus mijn eigen schuld dat ik voor het gemak van een community distro zoals Fedora kies, ik geef een ander niet de schuld van deze shortcut want het alternatief is het allemaal zelf uitzoeken.
Tja, als je “yum update” via cron elke nacht laat lopen is je leven een stuk kalmer. wat mensen wel eens vergeten is het ene met het andere vergelijken en dan de denk fout maken omdat we de ene club kwaliteit issues en lasten bij continue update hebben, dat dat dan ook elders zo moet zijn. bij mij kwamen de patches binnen en doorgevoerd vanzelf nog voordat de CVE bekend werd en ik heb hier NIETS aan hoeven doen behalve dan wat rukkers in mijn organisatie er van verwittigen dat er een hele belangrijke update uit was. pas toen ik ook de POC exploit, die zo te downloaden is op packetstorm, gedemonstreerd had, gingen de update engines elders pas aan. tja, amateurisme ten top onder het mom van ‘in theorie zou een update ook iets stuk kunnen maken’: ha dan gebruik je niet de juiste distros en vraag je eens af of een rotte update in de 15j waarvoor je een ‘yum history undo’ kunt doen op weegt tegen al die uren risico op pownage en ’turbulentie’ in je organisatie als er weer paniek gevoetbalt moet worden! je zou natuurlijk ook een fatsoelijke CI OTAP straat oid in kunnen richten om die auto updates te testen alvorens ze verder door te voeren. ik bedoel, bestaande functionaliteit testen omdat er een update is, dat soort tests, die zijn volledig te automatiseren (want anders is je ‘dienst’ niet goed gedefinieerd ook)!
De titel is onjuist!! Het was geen lek in Linux, het was een lek in Polkit. De term Linux verwijst naar de kernel. En in de kernel zat dit probleem niet.
Het belang van dit onderscheid is namelijk erg essentieel: Polkit wordt ook gebruikt op andere Unix-besturingssystemen, zoals BSD-systemen en waarschijnlijk ook Solaris.
Geen lek in linux, maar in polkit. Zo kan je het ook zien. Hadden we het laatst over mbt systemen en scope. Wat hoort nou bij wat, he. Heb inderdaad ook mn bsd systemen moeten patchen. Zelf hanteer ik vaak de regel dat als het niegoeh is, dan is het hunnie. Swa doet ook zoiets, denk ik als ik lees hoe hij zijn collega’s noemt.