Bug in pkexec maakt privilege escalation op meeste Linux-distro's mogelijk

Beveiligingsonderzoekers hebben een kwetsbaarheid ontdekt in pkexec, een component die in vrijwel alle Linux-distributies te vinden is. Met de PwnKit-exploit is het mogelijk rootrechten op een systeem te krijgen. Er zijn inmiddels proofs-of-concept die uitbuiting aantonen.

De kwetsbaarheid werd ontdekt door beveiligingsbedrijf Qualys en heeft code CVE-2021-4034 meegekregen, maar de onderzoekers noemen de bug ook PwnKit. De bug zit in pkexec, een functie binnen Polkit in Linux die het mogelijk maakt commando's uit te voeren als een andere gebruiker. Die feature wordt sinds 2009 in de meeste Linux-distro's standaard meegeleverd. Volgens de onderzoekers zit de specifieke kwetsbaarheid al sinds de eerste commit in de software en treft die dus potentieel veel gebruikers. De bug kan worden uitgebuit op systemen waarop een aanvaller toegang heeft tot lokale gebruikersrechten.

Volgens de onderzoekers zit er een geheugenbug in de feature. Daardoor is het mogelijk een out of bounds write op te roepen waar een aanvaller vervolgens een onveilige variable in kan zetten. Normaal gesproken wordt deze tegengehouden door de software, maar de onderzoekers vonden een manier om dat te omzeilen.

Hoewel de ontdekkers geen exploitcode publiceren, waarschuwen ze dat er waarschijnlijk snel exploits beschikbaar komen. Het lek zou namelijk 'heel eenvoudig' zijn en al die tijd makkelijk te spotten zijn geweest. Volgens BleepingComputer zijn er inmiddels al werkende exploits beschikbaar, die de site ook heeft getest.

De onderzoekers zeggen dat ze de bug succesvol wisten uit te buiten in Ubuntu, Debian, Fedora en CentOS, maar ze speculeren dat andere distro's 'waarschijnlijk ook kwetsbaar en uit te buiten zijn'. Ook niet-Linux-systemen zoals Solaris en *BSD zouden mogelijk kwetsbaar zijn omdat Polkit daar ook in zit, maar daarop hebben de onderzoekers geen praktische test gedraaid. OpenBSD is volgens hen in ieder geval wél veilig.

Qualys ontdekte de bug in november en heeft die vervolgens doorgegeven aan meerdere ontwikkelaars en fabrikanten. De originele Polkit-ontwikkelaars hebben een patch uitgebracht. De onderzoekers van Qualys noemen daarnaast een mitigatiemogelijkheid; met # chmod 0755 /usr/bin/pkexec worden de rechten van de tool aangepast, zodat authenticatie niet meer mogelijk is.

Reacties (70)

[kokx]

Werkende exploit code is ondertussen ook al even gepubliceerd.

Oftewel, draai je een Linux systeem, controleer of `pkexec` bestaat, en zo ja update polkit of voer sudo chmod 0755 /usr/bin/pkexec uit.

[Cybje]

Die mitigatie (chmod) werkt perfect inderdaad. De update is jammer genoeg nog niet overal beschikbaar, bijv. CentOS 7 heeft 'm nog niet. RHEL 7 wel, dus hij zal spoedig ook wel naar CentOS komen.

[Cilph]

Inderdaad ook gemerkt dat CentOS 7 nog vatbaar is, daarom de mitigatie maar toegepast.

[bazzi]

Hij is er!
https://centos.pkgs.org/7...12-26.el7.x86_64.rpm.html

[EWS99]

Ik merk dat op Azure de update voor RHEL 7 nog niet binnen komt. Voor RHEL 8 is er wel een update. Meer die daar last van hebben?

[MiKE_B]

polkit heb je zeker als je gnome of een andere DE hebt geinstalleerd, maar anders is het zeker niet standaard - op _mijn_ servers staat het nergens, op mijn debian laptopje wel. Bovendien is polkit niet linux-specifiek, ook op je FreeBSD machine-met-een-desktop heb je dit probleem.

Maar daarnaast is deze exploit alleen mogelijk als je al lokaal kan inloggen; aanvallers van buiten kunnen het dus alleen gebruiken als ze eers via een andere exploit op een niet-gepriviligeerd account kunnen inloggen.

[kokx]

Klopt! Het staat echt niet op alle servers. Maar de meeste servers met kubernetes of libvirt draaien het bijvoorbeeld wel. Vandaar het advies om te controleren of pkexec bestaat, ipv aan te nemen dat het niet op je server staat.

[svane]

Voor wie zich afvraagt hoe pkexec op een default installatie van Ubuntu-server komt:

• De laatste LTS versie (Focal) komt standaard met "software-properties-common".
• Software-properties-common is afhankelijk van packagekit.
• Packagekit is afhankelijk van policykit-1
• Policykit-1 bevat dan weer pkexec

(gevonden via `aptitude why policykit-1`)

Dit zijn nogal wat servers

[Spektaculair]

Ik krijg zojuist mail van Transip over een kwetsbaarheid in Polkit. Pkexec noemen ze helemaal niet. Maar ze bedoelen zo te zien hetzelfde issue: CVE-2021-4034

[Reactie gewijzigd door Spektaculair op 24 juli 2024 11:29]

[Anoniem: 718943]

Zelfde op Debian Buster gedaan:

`network-manager Depends policykit-1`

[Bastien]

Is gisteren gefixt voor Debian: https://security-tracker....ource-package/policykit-1 en https://security-tracker.debian.org/tracker/CVE-2021-4034

[Reactie gewijzigd door Bastien op 24 juli 2024 11:29]

[gepebril]

Bij mij leek:
sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade
sudo apt autoremove

Voldoende om Raspbian GNU/Linux 9 up te daten

Openmediavault kende geen usr/bin/pkexec

[Reactie gewijzigd door gepebril op 24 juli 2024 11:29]

[pixeled]

Voor wie op Arch zit: de fix zit ondertussen in polkit-0.120-4. Even pacman -Syyu en je bent weer veilig

[CAPSLOCK2000]

De andere grote distributies hebben de bug gelukkig ook al opgelost. Dat wordt tegenwoordig vooraf gecoordineerd zodat iedereen z'n oplossing klaar heeft staan op het moment dat het probleem bekend wordt gemaakt.
Vervolgens de hele wereld zo ver krijgen dat die patches snel geinstalleerd worden is overigens een heel ander verhaal. Tal van organisaties die weken of maanden hebben tussen patchmomenten.

Tip: als je bang bent om te patchen tijdens je werkdag dan ben waarschijnlijk het verkeerde probleem aan het oplossen. Als iets belangrijk genoeg is dat het niet stuk mag gaan "tijdens kantooruren" dan zul je sowieso iets aan high-availability / fail-over moeten doen. Als je dat toch hebt dan kun je ook systemen vrij maken om ze te patchen en te testen, automatisch uiteraard.

[mjtdevries]

Als iets belangrijk genoeg is dat het niet stuk mag gaan "tijdens kantooruren" dan zul je sowieso iets aan high-availability / fail-over moeten doen.

Veeeeel te kort door de bocht.
Je kunt prachtige high-availability / fail-over hebben, maar dat betekent niet dat je geen productie verlies hebt wanneer je een roll-back moet doen.

Gelukkig gaat het hier puur om het OS, waar dat minder een issue is.

[Reactie gewijzigd door mjtdevries op 24 juli 2024 11:29]

[jeff2]

Het principe van high-availability / fail-over is dat je 100% uptime kunt hebben en toch bijvoorbeeld updates kunt doen zonder enige downtime.
Bij het moeten doen van een rollback op een node zul je dan dus geen downtime hebben van het systeem.

[mjtdevries]

Als je update alleen de node raakt klopt dat. Als je update ook de data erachter raakt dan klopt het niet.

[TheVivaldi]

In Void Linux ook al sinds vanmorgen.
sudo xbps-install -Su

[Andreas01]

Op openSUSE Tumbleweed ook de update gekregen, en volgens de website gelinkt door @Krystman is hij ook al beschikbaar voor Leap 15.3.

[orvintax]

Welke mirrors gebruik jij? Ik gebruik de worldwide rackspace mirror (en daarnaast nog wat nederlandse) en ik krijg niks

[Hardwareseller]

- knip -

Admin-edit:

Het plaatsen van exploits of links hier naartoe is niet toegestaan

[Reactie gewijzigd door Bor op 24 juli 2024 11:29]

[mmjjb]

Heb zojuist bovenstaande en een andere geprobeerd onder een test user op Centos 8 en geen van beide hadden success.

bash$ ./test
[~] compile helper..
[~] maybe get shell now?
Cannot run program lol: No such file or directory

-knip-
bash$ ./cve-2021-4034-poc
GLib: Cannot convert message: Could not open converter from “UTF-8” to “PWNKIT”
The value for the SHELL variable was not found the /etc/shells file

This incident has been reported.


[root~]# /usr/bin/pkexec --version
pkexec version 0.115


De onderste triggert gelukkig zelfs een incident

[Reactie gewijzigd door Bor op 24 juli 2024 11:29]

[CurlyMo]

Dat staat in de CVE toegelicht:

g_printerr() normally prints UTF-8 error messages, but it can print
messages in another charset if the environment variable CHARSET is not
UTF-8 (note: CHARSET is not security sensitive, it is not an "unsecure"
environment variable).

Dus even je default charset veranderen.

[mmjjb]

Thanks voor de reactie. Had dat stuk gemist in de CVE. Heb de charset aangepast onder de user sessie maar blijft het zelfde. Wellicht dat het alleen werkt als het system wide niet op UTF-8 draait?

Als dat laatste het geval is dan zal de impact wel meevallen; aangezien de meeste servers standaard op UTF-8 staan.

[Palmachius]

Op CentOS 7 werkt dit, je krijgt een root shell. Het installeren van een nieuwe polkit (0.120) lost het op.

Helaas moet polkit wel vanaf source geïnstalleerd worden omdat ik er geen binary pakket voor dit OS voor kon vinden. Hiervoor had ik ook nog ICU en JS nodig.

[welmers]

Ik zou gewoon chmod 0750 /bin/pkexec doen tot er een update is. Scheelt hoop werk vgl met from source installeren.

[svane]

Interessant, bedankt!

Op Ubuntu 20.04.3 LTS werkt dit inderdaad:

➜ ~ ./a.out
[~] compile helper..
[~] maybe get shell now?
# whoami
root

De volgende bestanden worden aangemaakt:

'GCONV_PATH=.'
payload.c
payload.so
lol/gconv-modules

Na een upgrade lijkt alles weer te werken zoals 't zou moeten

➜ ~ ./a.out
[~] compile helper..
[~] maybe get shell now?
pkexec --version |
--help |
--disable-internal-agent |
[--user username] PROGRAM [ARGUMENTS...]

[Reactie gewijzigd door svane op 24 juli 2024 11:29]

[Anoniem: 1617016]

"De bug kan worden uitgebuit op systemen waarop een aanvaller toegang heeft tot lokale gebruikersrechten."
Betekent dat iemand die SSH toegang heeft? Alsin, als ik geen SSH-gebruikers heb anders dan mezelf, ben ik dan veilig?

[ApexAlpha]

In principe wel. Maar het kan met élk low-privilege user account. Dus ook als je via een andere exploit via de webserver of zo binnen komt.

Maar als niemand anders code op je computer kan uitvoeren ben je in principe veilig tegen privilege-escalation exploits zoals deze.

[RienBijl]

Ja, maar dat is een hele slechte aanname om te maken. Combineer dit bijvoorbeeld met Log4J van een tijdje geleden en dat hele plannetje valt uit elkaar. In combinatie met RCE is dit gewoon dodelijk.

Dus theoretisch, ja. Praktisch? Asap patchen.

[Reactie gewijzigd door RienBijl op 24 juli 2024 11:29]

[devices]

Ligt ook aan je stack. Als je processen hebt ingedeeld met SELinux context, kan je zelfs met root niks wat dat proces ook niet al kan. Neem je de webserver over en krijg je root, kan je alsnog niet buiten /var/www (tenzij je dat hebt ingesteld) en geen andere processen stoppen/starten.

[Magic Power]

Iemand moet kunnen inloggen op het systeem, dan is de bug misbruikbaar. Als je anderen geen toegang tot je systeem geeft, is het dus niet te misbruiken. Als je een SSH server erop hebt draaien (en goed beveiligd), maar alleen jij kan inloggen, ben je dus niet kwetsbaar.

Zorg er wel voor dat je zo snel mogelijk het systeem update om de polkit update uit te voeren.

[mjz2cool]

Dit is wel gevaarlijk, want dan ga je er vanuit dat er geen andere exploits in je systeem zitten. Als iemand op wat voor manier dan ook toegang krijgt tot een lokale user kan diegene misbruik maken van deze pkexec exploit.

[Anoniem: 718943]

Als iemand door een gaatje ergens in een website iets uit weet te voeren als bijv. www-data, dan kun je te maken hebben met escalatie naar root door die aanvaller. Dus nee, dan ben je niet per definitie veilig.

[SambalBij]

Hoe standaard is dit? Volgens artikel standaard meegeleverd, maar op mijn Debian servers kom ik het niet tegen... Wordt zo te zien niet standaard geinstalleerd?

[elmuerte]

polkit wordt vaak non-root users wel bepaalde privileges zaken moet kunnen uitvoeren. Zaken waar sudo niet toereikend is.
Op een standaard server kom je het niet heel vaak tegen. Op een desktop install vaak wel.

Sudo heeft een nogal beperkte configuratie constructor, waar polkit doormiddel van JavaScript veel complexere configuratie mogelijkheden heeft. https://www.freedesktop.o...docs/latest/polkit.8.html

[Kees]

Op een desktop kom je het vaak tegen omdat onder andere gdm en gnome er een dependency op hebben.

Op ubuntu servers heeft bijvoorbeeld ubuntu-standard er een dependancy op (via language-selector-common -> accountservice -> software-properties-common -> packagekit -> policykit-1).

[Tozz]

Wij zien het inderdaad ook nergens op onze Debian en Ubuntu machines. RedHat/CentOS wel.

Bij een paar honderd machines die ik in beheer heb is deze software nergens geinstalleerd.

[Anoniem: 718943]

Ik ben het bij mij tegengekomen op CentOS (8 ), ubuntu (focal) en debian (buster). Op geen van allen expliciet geinstalleerd, dus zit of in base install, of komt als dependency mee met bijv. docker oid.

resp.: Base install, ubuntu-server, network-manager

(En bij raspbian komt het ook mee als dep met de network-manager )

[Reactie gewijzigd door Anoniem: 718943 op 24 juli 2024 11:29]

[Marve79]

Hiervoor heb je al user access nodig op het systeem neem ik aan?

[Anonymoussaurus]

Ja:

De bug kan worden uitgebuit op systemen waarop een aanvaller toegang heeft tot lokale gebruikersrechten.

[Tozz]

Ja, maar vergeet niet dat bijvoorbeeld een hosting account hebben genoeg is. Als je met FTP bestanden kunt uploaden en je kunt een PHP script aanroepen die deze exploit kan uitvoeren ben je er al.

Je hebt dus geen login account nodig. De mogelijkheid om binaries uit te voeren is voldoende.

[Anoniem: 718943]

Hiervoor moet je iets uit kunnen voeren. Dus via shell, maar ook foothold via een of andere exploit. Dus denk niet dat als je geen shell open hebt staan voor users dat je geen risico loopt.

[himlims_]

- pkexec is installed by default on all major Linux distributions

in artikel(en de bron) wordt gesuggereerd dat het pakket standaard onderdeel is van het OS. Hier 20 debian bakken nagelopen; nergens geïnstalleerd. lijkt me geen pakket wat default geïnstalleerd wordt (onder debian), ubuntu is dit wel een standaard onderdeel

daarlangs zou iemand al toegang tot je systeem moeten hebben, wil dit te exploiteren zijn (ben je sowieso al fcked)

//edit; @SambalBij volgens mij gooit ubuntu hem er wel gratis op

[Reactie gewijzigd door himlims_ op 24 juli 2024 11:29]

[SambalBij]

Ja dat vroeg ik me inderdaad ook af. Er zit wel iets genaamd polkit in de standaard Debian repo, maar dat wordt zo te zien niet default geinstalleerd.
(Ik had er tot vandaag ook nog niet eens van gehoord. Functie om iets als een andere gebruiker uit te voeren klinkt meer als su/sudo...)

edit:
Ubuntu gebruik ik dan weer niet, mij iets te cutting-edge voor een server

[Reactie gewijzigd door SambalBij op 24 juli 2024 11:29]

[Tozz]

Inderdaad, hier ook enkele honderden machines met Ubuntu/Debian en nergens gevonden. CentOS wel.

[mjz2cool]

Het gaat volgens mij vooral om de desktop distro's. Polkit wordt gebruikt om zonder root rechten bijvoorbeeld een wifiverbinding te maken, of om gebruikers te beheren.

[AW_Bos]

Als ik de mitigatie gebruik met chmod 0755 /usr/bin/pkexec, welk proces blokkeer je dan daarmee? Oftewel, wanneer zou je pkexec willen uitvoeren op de manier zoals het hoort?

[Reactie gewijzigd door AW_Bos op 24 juli 2024 11:29]

[devices]

Je verwijderd daar blijkbaar de s-flag mee, de setuid flag.

[AW_Bos]

Ja, maar blokkeer je dan niet bepaalde dingen daarmee? Niet dat er door deze mitigatie iets vastloopt...

[Anoniem: 85014]

Dan kan polkit geen root rechten meer geven aan processen opgestart door een user die niet root is.