Bug in 'needrestart' maakt uitvoeren van rootcommando's Ubuntu Server mogelijk

Beveiligingsonderzoekers van Qualys hebben vijf kwetsbaarheden gevonden in de needrestart-functionaliteit van Ubuntu Server. Met het uitbuiten van die kwetsbaarheden is het mogelijk om roottoegang tot een OS te krijgen, al is daar wel aanvankelijke toegang voor nodig.

De vijf kwetsbaarheden werden ontdekt door de Threat Research Unit van securitybedrijf Qualys. Het gaat om vijf verschillende local privilege escalations die in versie 0.8 van needrestart zitten. Die versie werd in april 2014 in Ubuntu Server 14.04 geïntroduceerd en wordt sindsdien standaard meegeïnstalleerd. Alle versies van needrestart tot aan 3.8 zijn kwetsbaar. Daarnaast is het mogelijk dat ook Linux-distro's de tool gebruiken of dat gebruikers die zelf hebben geïnstalleerd. Dat kan op zowel Ubuntu Server als Ubuntu Desktop, maar ook op andere distro's.

Kwetsbare versie	Gepatchte versie
24.10 oracular	3.6-8ubuntu4.2
24.04 LTS noble	3.6-7ubuntu4.3
22.04 LTS jammy	3.5-5ubuntu2.2
20.04 LTS focal	3.4-6ubuntu0.1+esm1
18.04 LTS bionic	3.1-1ubuntu0.1+esm1
16.04 LTS xenial	2.6-1ubuntu0.1~esm1

Needrestart is een tool die het systeem scant om te bepalen of een herstart nodig is, bijvoorbeeld als bepaalde packages op de achtergrond zijn bijgewerkt. Qualys-onderzoekers zeggen dat ze vijf verschillende kwetsbaarheden hebben ontdekt, die los van elkaar de mogelijkheid bieden om code uit te voeren op rootniveau.

Qualys heeft de kwetsbaarheden beschreven in een apart document. Voor iedere kwetsbaarheid is lokale toegang tot een machine nodig, bijvoorbeeld via een andere hack of door fysieke toegang te krijgen. Ubuntu-maker Canonical heeft patches uitgebracht voor de kwetsbaarheden, maar noemt daarnaast ook een mitigatie. Beheerders kunnen /etc/needrestart/needrestart.conf bewerken en $nrconf{interpscan} = 0; achter de rij # Disable interpreter scanners zetten.

CVE	Omschrijving	Ernstigheid
CVE-2024-48990	Aanvallers kunnen needrestart de Python-interpreter laten draaien met een eigen variabele	CVSS 7.8 High
CVE-2024-48992	Aanvallers kunnen needrestart de Ruby-interpreter laten draaien met een eigen variabele	CVSS 7.8 High
CVE-2024-48991	Aanvallers kunnen een race condition timen en een eigen, nagebootste Python-interpreter draaien	CVSS 7.8 High
CVE-2024-10224	De Modules::ScanDeps-library kan soms bepaalde input accepteren die het mogelijk maakt een pesky pipe te openen	CVSS 5.3 High
CVE-2024-11003		CVSS 7.8 High

Reacties (15)

[zordaz]

Wat wordt precies bedoeld met 'aanvankelijke toegang nodig'?
Ik kreeg vandaag trouwens een update binnen op mijn Debian Bookworm systeem voor deze component, daarmee is het volgens mij opgelost.

[Kees]

Je moet al (shell) toegang hebben tot de server, je kan dus niet zomaar root worden zonder dat je eerst toegang hebt (legaal of door het hacken van iets anders).

Het is een privilege escalation, oftewel het ophogen van je toegang. Je moet dus eerst al toegang hebben.

Zie het als een kluisdeur die open staat, ook al is dat onveilig, je zal toch eerst het gebouw in moeten komen om er misbruik van te kunnen maken. Dat kan wellicht als je er werkt, of als je er inbreekt.

[Reactie gewijzigd door Kees op 22 november 2024 15:13]

[xylone]

Mooie metafoor die je daar maakt!

@zordaz In de derde alinea wordt het nog specifiek genoemd.

Ontopic: Ik dacht bij de header meteen aan een groot probleem, maar als je eerst toegang moet hebben valt het mee. Maar dat het opgelost moet worden is overduidelijk. Hoop ook dat ze wel op tijd Canonical en andere distro's hebben ingelicht.

[zordaz]

Ah, tnx. Dan had dat beter gelijk ook zo in de eerste alinea genoemd kunnen worden natuurlijk. Lokale toegang is meteen duidelijk. Ljjkt slecht vertaald of zo...

[Reactie gewijzigd door zordaz op 23 november 2024 09:49]

[lenwar]

Een kluis die open staat in een afgesloten gebouw. Dat vind ik wel een aardige analogie. Die ga ik onthouden.

Het vervelende in deze is, is dat het voldoende is om de Python-interpreter iets te laten doen. Er zijn gigantisch veel mechanismes die Python-code uitvoeren op machines. Uiteraard moet je wel toegang hebben tot die mechanismes, maar het is wel echt superbreed.
Het verschilt dus gigantisch hoe accuut dit probleem is.

[daft_dutch]

en als je een blue-team security team hebt. Heb je bewakers in je gebouw rondlopen.

[- peter -]

Dit is ook iets wat ik altijd gelijk uninstall op een verse VM/Ubuntu server. Gedoe altijd met onnodige vragen over restarts na apt-get upgrade.

[Mijzelf]

Hoe doe jij het dan? Zowiezo rebooten, of een educated guess doen welke daemons moeten worden hergestart, of ...?

[Cybje]

Ik doe vaak een volledige reboot na patching van een server. Dan weet je ook zeker dat alles herstart is en in schone staat is. Maar ik werk meestal in HA omgevingen, dus het is een kwestie van die server in 'maintenance mode' zetten in de load balancer en dan rebooten. Dus daar merkt niemand iets van.

Heb al te vaak meegemaakt dat vooral bij updates van libraries er toch weer ergens een service is die er niet 100% happy mee is. Zo had ik een keer een update in libpng die ervoor zorgde dat PHP niet meer goed functioneerde. Dat was niet te zien, behalve dan doordat elke request een HTTP 500 terug kreeg. Dus na patching leek alles in orde, tot ik de server weer activeerde in de load balancer, bleek dat die server niet door de health check heen komt. Nou is dat ook het nut van een health check natuurlijk, maar ik ben dit soort dingen liever een stapje voor. En ik weet dat er genoeg omgevingen zijn waar de health checks echt niet verder gaan dan een simpele TCP probe, dus dan was het simpelweg misgegaan.

Die server draaide trouwens Ubuntu en had gewoon 'needrestart'. Ik weet alleen niet meer zo of die server php-fpm gebruikte of mod_php in Apache.

Anyway, dat was 1 voorbeeld. Het gebeurt niet vaak. Maar na 20 jaar Linux servers beheren heb je het wel een paar keer meegemaakt.

[Reactie gewijzigd door Cybje op 22 november 2024 18:28]

[paradoXical]

Waar ik werk is een reboot niet zonder meer mogelijk. Dat gaat via een change welke vervolgens besproken wordt, teams worden op de hoogte gebracht, daarna kan ik dit pas uitvoeren.

Een patch zonder noodzakelijke herstart is soms erg handig. Lang leve HA!

[Cybje]

Bij ons moeten patches uiteraard ook altijd via een change, maar een belangrijke security patch (critical CVE) mag wel via een 'emergency change' en die wordt vrijwel direct goedgekeurd of afgekeurd. Bij ons moeten zelfs patches zonder reboot nog via een change. Uiteindelijk is het gewoon een kleine verandering in de infrastructuur namelijk, zelfs al wijzigt er bij een security patch normaliter niet iets aan de functionaliteit.

Het hele proces van een triage doen, change aanmaken, change goedgekeurd krijgen bij ons eigen team en bij de klant (incl. op de hoogte stellen van beide) hoeft niet echt meer dan een half uur te duren.

[- peter -]

T zijn geen productie servers, dus ik reboot meestal alleen als er een kernel wijziging is. Of de hele VM host als ik alle VMs even afga.

[xilanaz]

Ben er ook niet zo blij mee, ongevraagd services herstarten die mogelijk een afhankelijkheid zijn van andere services die daardoor ook herstarten, nee dank je. Voor dat ze dit hadden kreeg je een lijst met services, dan had je wat meer controle en kon je kiezen wat wel en wat zeker niet.

[syl765]

Het is weer zo'n service waar eigenlijk niemand om vraagt maar er gewoon weer tussen gefietst word. Ubuntu heeft wel meer van dat soort trekjes. Het is wat dat betreft een uiterst onstabiel OS. Iedere release weer een nieuwe service, of halfbakken oplossingen voor problemen die er niet zijn. Je loopt daardoor soms te zoeken naar zaken die totaal niet duidelijk zijn. Config aanpassingen werken niet meer omdat er weer iets tussen is geplaatst. Denk een systemd-socketd voor je ssh daemon. Reden je kan 3MB geheugen besparen, ondertussen gebruikt snapd 30MB... ik snap het niet.

[wica]

Een knullige fout zo te lezen.

For example, in our exploit we run a simple Python process (which
sleep()s forever) with a "PYTHONPATH=/home/jane" environment variable,
and plant a shared library "importlib/__init__.so" in our /home/jane.
As soon as needrestart executes Python with our PYTHONPATH environment
variable (at line 203), our shared library is executed (by Python's
initialization code) and creates a SUID-root shell in /home/jane