Is dit alleen bij de Linux kernel het geval of bij ieder Nix achting systeem?.

Er staat toch bij in welke versies het probleem allemaal zit?

Ik wordt wel een beetje moe van het constant updaten van alles de laatste tijd. Niet alleen met LNX. MS is natuurlijk nog veel erger met z'n monsterlijk grote updates iedere maand.

Geldt alleen voor Linux kernels vanaf 5.8, andere *nix besturingssystemen zijn niet kwetsbaar.

En dan nog niet eens alles. Bijvoorbeeld Red Hat zou qua kernel versies (de code is ge-backport) kwetsbaar zijn, maar het PoC werkt daar niet.

Een 'lokale gebruiker', wie doet je wat als je niemand achter je computer laat?
Storm in glas water?
Paniek om niks?
Misschien dat het voor een bepaalde groep wel interessant is om te weten dat dit kan gebeuren als je iemand anders aan je Linux pc laat zitten maar voor het gros zal dit niet spelen of zie ik dat verkeerd?

Even worse...


https://nakedsecurity.sophos.com/2022/03/08/dirty-pipe-linux-kernel-bug-lets-anyone-to-write-to-any-file/

Het scheelt natuurlijk wel dat een update op Linux binnen no-time gedraaid is. Onder Windows ben je wel even zoet, mag opnieuw opstarten en moet je ook weer wachten na het opstarten omdat het systeem weer de boel moet configureren. Dat is pas irritant.

Wel weer kudos voor de Linux-boys om de patch er weer zo snel doorheen te jassen zodat we weer veilig(er) zijn. Op een ander besturingssysteem mag je soms een maand (of langer) wachten vooraleer je systeem voorzien is van een pleister.

Moet juist zeggen dat het bij MS mee valt, nu toevallig weer een ernstig ding voor Exchange maar verder enkel eenvoudige patches maar geen kritieke lekken.

Local user als iemand die geauthentiseerd is op je systeem en commando's via pipes mag geven.
Een system commando via ene php script zou dit al kunnen doen dus.

RHEL 8 zit op 4.18. Die is niet kwetsbaar.

Ook voor Linux desktop users kan Dirty Pipe een risico vormen. Je hoeft maar op een linkje te klikken die een exploit binnen haalt en deze uitvoert als jouw user. Vervolgens zou de exploit allerlei dingen als root kunnen doen op jouw Linux desktop. Risico is inderdaad wel nihil want een willekeurige Linux desktop is geen heel interesant doelwit.

Voor servers is het een ander verhaal. Aan het internet hangt een enorm aantal multi-user Linux servers en als die een kwetsbare kernel draaien zou een kwaadwillende user root kunnen worden op zo'n server en vervelende dingen kunnen doen. Of een user zou op de een of andere manier onbewust een exploit binnen kunnen halen en een achterdeurtje met root access kunnen creëren.

Bij kernel updates zul je je Linux systeem toch nog wel opnieuw moeten starten, tenzij je een systeem draait waarbij je live kernel updates kan doen.

Redhat RHEL7 ook niet. 8 wel maar daar werken de exploits niet.

Dat is niet waar. Onder Linux komt alles read only binnen als je op een linkje klikt. Je zal dus eerst het execute bitje moeten setten en dat kan die exploit niet zelf.

Het gaat bij "lokale gebruikers" niet alleen om gebruikers die fysiek via een rechtstreeks aangekoppeld toetsenbord en beeldscherm toegang tot de computer hebben, het gaat om alle processen die op zo'n systeem draaien met beperkte rechten.

Er zijn bijvoorbeeld Linux-machines waar tientallen, honderden of zelfs duizenden mensen via ssh op kunnen inloggen. Al die gebruikers kunnen dit lek misbruiken om root-rechten te krijgen. Ik weet niet of KPN het inmiddels de nek heeft omgedraaid, maar toen ik nog bij XS4ALL zat had iedere klant ssh-toegang tot shell-servers van XS4ALL.

Of neem een webhostingbedrijf waar klanten via allerlei frameworks de meest uiteenlopende websites hebben draaien. Zo'n webserver draait op zo'n server als een lokale gebruiker met beperkte rechten. Als in een van die vele websites een zwakheid zit die het voor een bezoeker mogelijk maakt een unix-commando te lanceren, dan kan die via dit lek buiten de beperkte van de webserver treden en als root toegang krijgen tot het hele systeem en alle websites die erop draaien.

Linux wordt echt niet alleen op pc's, personal computers, gebruikt. Het wordt ook op systemen gebruikt waar dit soort beveiligingslekken wel degelijk een joekel van een probleem kunnen zijn.

Grote beveiligingslekken zijn vaak aaneenschakeling van kleinere lekken. In het voorbeeld van die webhoster met een zwakke website heeft een aanvaller twee zwakheden nodig: de eerste om een zelf gekozen proces als lokale user met de beperkte rechten van het webserverproces te starten, de tweede om vanuit dat zelf gekozen proces root-rechten te bemachtigen zodat de aanvaller opeens alles op de server mag.

Omdat een lek als dit makkelijk gevaarlijk kan worden in combinatie met zoiets als een lek in een website op een server van een hostingprovider is het geen storm in een glas water, het oplossen van dit soort lekken voorkomt dat het echt gaat stormen.

Dat is niet waar. Onder Linux komt alles read only binnen als je op een linkje klikt. Je zal dus eerst het execute bitje moeten setten en dat kan die exploit niet zelf.[/quote]Hint: citeer het deel waarover je reactie gaat, en niet van alles eromheen. Dat maakt je reactie een stuk duidelijker.

Het is waar dat Linux (en elke Unix) een eenvoudige maar zeer doeltreffende drempel opwerpt tegen dit soort dingen: een bestand is uitvoerbaar/executable niet op basis van een extensie (zoals .exe), maar op basis van een executable-bit die niet automatisch wordt aangezet.

Maar onderschat niet het destructieve vermogen van digibeten die denken dat ze er verstand van hebben of die denken dat de computer er verstand van heeft. Ik heb in het verleden[*] pc's van vrienden virusvrij gemaakt, dichtgetimmerd met een degelijke virusscanner en wat in die tijd nog meer nodig was, om na korte tijd de hele exercitie te kunnen herhalen op een pc die stijf stond van de virussen omdat een "handige" buurman die virusscanners maar onzin vond alles er weer af had geflikkerd, in combinatie met de neiging van die digibete vrienden om in geval van twijfel maar wél op iets te klikken en wél ja te zeggen tegen dingen die ze niet snapten, omdat ze aannamen dat de computer het wel beter zou weten dan zij zelf. Al die malware en phising-aanvallen die werken omdat mensen heel dom instructies opvolgen, tegen alle waarschuwingen in die het systeem geeft, bevestigen het beeld.

[*] Ik ben daarmee zo'n 12 jaar geleden gestopt toen ik zelf al zo'n 10 jaar geen Windows meer gebruikte, buiten werkstations in werkomgevingen die door anderen beheerd werden en waar ik alleen maar een "domme" gebruiker van was.

Weet jij dan, hoelang dit probleem bestond voordat het gepatcht werd en openbaar gemaakt werdt?

Klopt, je hebt helemaal gelijk, ik ging te scherp door de bocht. Bedankt voor de opheldering!

Een goede SELinux policy verhinderd dat een dergelijke exploit überhaupt opstart, zelfs als de execute bit van de file van de geïnfiltreerde malware aan zou staan. Het komt bij IT security altijd aan op een meervoudige en gelaagde defensie.

https://www.datadoghq.com/blog/dirty-pipe-vulnerability-overview-and-remediation/

sinds kernel 5.8 van augustus 2020 .

Fixed (zonder melding dat het een security probleem was) - 21/23 feb 2022 .

7 maart : public disclosure .

Hint: citeer het deel waarover je reactie gaat, en niet van alles eromheen. Dat maakt je reactie een stuk duidelijker.

Het is waar dat Linux (en elke Unix) een eenvoudige maar zeer doeltreffende drempel opwerpt tegen dit soort dingen: een bestand is uitvoerbaar/executable niet op basis van een extensie (zoals .exe), maar op basis van een executable-bit die niet automatisch wordt aangezet.

Maar onderschat niet het destructieve vermogen van digibeten die denken dat ze er verstand van hebben of die denken dat de computer er verstand van heeft. Ik heb in het verleden[*] pc's van vrienden virusvrij gemaakt, dichtgetimmerd met een degelijke virusscanner en wat in die tijd nog meer nodig was, om na korte tijd de hele exercitie te kunnen herhalen op een pc die stijf stond van de virussen omdat een "handige" buurman die virusscanners maar onzin vond alles er weer af had geflikkerd, in combinatie met de neiging van die digibete vrienden om in geval van twijfel maar wél op iets te klikken en wél ja te zeggen tegen dingen die ze niet snapten, omdat ze aannamen dat de computer het wel beter zou weten dan zij zelf. Al die malware en phising-aanvallen die werken omdat mensen heel dom instructies opvolgen, tegen alle waarschuwingen in die het systeem geeft, bevestigen het beeld.

[*] Ik ben daarmee zo'n 12 jaar geleden gestopt toen ik zelf al zo'n 10 jaar geen Windows meer gebruikte, buiten werkstations in werkomgevingen die door anderen beheerd werden en waar ik alleen maar een "domme" gebruiker van was.[/quote]Een exploit binnenhalen is natuurlijk wat anders dan een bestand binnenhalen en uitvoeren.

Toegegeven, voordat een browser-exploit dit lek kan misbruiken, zal het eerst uit de sandbox moeten breken, dus dat betreft meteen een keten van 3 lekken. Foute pagina bezoeken-> Code Execution in de Content Renderer -> Code Execution in het Central Process van de browser -> Root access via Dirty Pipe.

... en dan speel ik het zelf klaar bij een opmerking over citeren een fout in de quote-tags te maken (in bovenstaand citaat hersteld). Excuses daarvoor.

SELinux policies zijn toch maar een pain in the ass hoppa meteen SELINUX=disabled ... toch ... ?


;-)

Openbaar 20 feb, de eerste patches 23 feb.

Beter lezen, beter antwoorden.

zie 10 mar 22:34

De bug ontstond en werd kritiek op 20 mei 2020, zo valt uit de rapportage van Max Kellermann op te maken:

https://dirtypipe.cm4all.com/#uninitialized



De bug werd gerapporteerd op 20 februari 2022.

https://dirtypipe.cm4all.com/#timeline


In een professionele Linux werkomgeving werd de bug dus gerepareerd ruim voordat deze publiekelijk werd. Desondanks was er 21 maanden sprake van een gapend gat. Men mag hopen dat men tussentijds goed heeft gemonitord.

Dat klopt, maar de Linux 5.8 kernel kwam pas op 2 augustus 2020 uit. Dat scheelt weer 2,5 maand aan logs analyseren.

Nou dat weet ik niet, de updates in bijvoorbeeld Debian kwamen pas net voor die public disclosure uit en kennelijk
ging daar nog wat in fout want de 5.10.0-11 versie werd een dag later (7 maart) nog weer door een 5.10.0-12 vervangen.
Ik heb uiteraard unatended-upgrades draaien met auto reboot midden in de nacht (wat dus 2 dagen achtereen gebeurde)
maar toch denk ik niet dat dit "ruim voor deze publiekelijk werd" gerepareerd is.
Waarschijnlijk is door het (achterlijk) grote aantal Linux distributeurs het informeren daarvan inmiddels al gelijk aan
"publiekelijk maken" en doet men dat dus pas in die fase.

Oh ja, openbaar 20 feb, de eerste patches 23 feb.


De kwetsbaarheid, die ook wordt aangeduid als CVE-2022-0847, werd op 20 februari door Max Kellermann aan het securityteam van de Linux-kernel gerapporteerd. Een dag later werd ook het Android-securityteam ingelicht.

Op 23 februari verschenen de eerste Linux-updates.

Natuurlijk... Of dacht je dat je moest wachten op patchdinsdag of zoiets?

Je kunt echt niet lezen blijkbaar .
Ook 11 mar 12:21 legt het goed uit.

De vraag hoe lang de kwetsbaarheid bestond werd gesteld - en dat is sinds mei 2020 (introductie in een rc), of eventueel augustus 2020 (release van de eerste kernel met de bug) .

Nee - een disclosure melding aan de "leverancier" (20 feb 2022) is niet wat je normaal "openbaar maken" noemt .
Dan werd de patch (waar je echt zo niet uithaald dat het security gerelateerd is) op 23 februari gereleased .

Openbaar maken is de melding _dat_ er een exploitable bug was en hoe die werkt - en dat is dan 7 maart .

bug ontstond en werd kritiek op 20 mei 2020, zo valt uit de rapportage van Max Kellermann op te maken:
Dus ja, schijnbaar hadden ze geen haast met fixen

SELinux help niet in dit geval. SELinux is een Linux Security Module. In de regel is SELinux afhankelijk van een veilige kernel. Soms helpt SELinux zelfs als de kernel gecompromiteerd is maar dat is dan een kwestie van geluk.

Bug is niet kritiek maar medium https://advisories.ncsc.nl/advisory?id=NCSC-2022-0153 en volgens redhat belangrijk.
Daarnaast is Linux geen monocultuur zoals windows. Mijn systemen (rhel7) waren niet eens kwetsbaar en voor die systemen die dat wel waren snel gefixt. Overal zitten gaten in dat is op zich niks bijzonders, je moet ze wel eerst zien te vinden. In het geval van Linux zijn er veel security mensen die naar de code kijken. Dat is een prettig gevoel.

Snel gefixt? Duurde bijna 2 jaar!

Op de Linux systemen waar ik mee werk, daar hebben de ongeprivilegieerde gebruikers geen rechten om de execute permissies van de scripts of binaries met chmod(1) aan te zetten of te wijzigen, omdat het gevoerde SELinux beleid dat uitsluit. Dat bemoeilijkt het uitvoeren van een Dirty Pipe aanval aanzienlijk, temeer omdat we ook 2FA tokens gebruiken.

De ontdekking van deze kernel bug vergde 18,5 maand. De oplossing vinden kostte minder dan 3 dagen. De uitrol nam luttele minuten in beslag. In ons geval vond de bijwerking 's nachts in de Livepatch modus plaats, dus zonder herstart.

Dus inderdaad snel gefixt. We hoefden niet tot patch dinsdafg te wachten.

Dingen zoals geen compilers hebben en/of schrijfbare locaties met noexec mounten kunnen dingen voorkomen maar dat is vaak niet echt wenselijk. Daar heb je in principe SELinux ook niet voor nodig. Maar ja idd er zijn mogelijkheden.

Dat is het resultaat van zo lang lek zijn. En dan ben je nog blij ook. Rare jongens, die Linux fans.

O en ook je hebt geen execute nodig om scripts uit te voeren want die worden geinterpreteerd. Daarnaast zijn er natuurlijk meerdere manieren om dit problem te misbruiken (supply chain attack bijvoorbeeld). Gewoon altijd zsm je kernel bijwerken.

Ik wil graag er even op wijzen dat er bij open source er ook geen garantie is dat zaken op korte termijn worden opgelost.(heartbleed openssl is geruime tijd over het hoofd gezien, behalve door de NSA)

Met flame wars worden zaken niet opgelost.

Het is natuurlijk niet echt een grote moeite, als je niet al automagisch hebt ingested dat hij periodiek update. Maargoed. En moet je wat betreft dit lek wel updaten? Heb jij kernel 5.8+? Of een voorgaande versie die gebruikelijk zou zijn bij een mainstream Linux, ubuntu, mint, debian, etc. Arch weet ik niet, maar die zijn wel bleeding edge. Daarbij zou je trouwens ook een betere update strategie moeten hebben dan: ik word er moe van.... Toch, neem ik aan?

Weet jij hoeveel gebruikers bij een hosting partij zitten? 20.000 tot 50.000 op een shared cluster?

Elk process is geassocieerd met een "lokale gebruiker". Het is miscleidend om de indruk te wekken dat dit probleem zich beperkt tot een PoC waar je een stukje c code compileert en uitvoert in een shell. Elk process kan deze fout gebruiken om de beveiliging te omzeilen. Hoeft niet eens opzettelijk te zijn.

Het is gewoon een gapend gat

Lek is het pas als het is ontdekt! Als het eerder was ontdekt en misbruikt hadden we berichten moeten lezen over versleutelde Linux servers en die zijn er niet.