image

Dirty Pipe-lek in Linux-kernel kan lokale gebruiker rootrechten geven

donderdag 10 maart 2022, 11:55 door Redactie, 47 reacties

Een nieuwe kwetsbaarheid in de Linux-kernel, met de naam Dirty Pipe, maakt het mogelijk voor ongeprivilegieerde lokale gebruikers om code in rootprocessen te injecteren en zo rootrechten te krijgen. Beveiligingsupdates zijn inmiddels voor allerlei distributies beschikbaar gemaakt.

De kwetsbaarheid wordt Dirty Pipe genoemd vanwege de onveilige interactie tussen een Linux-bestand, dat permanent op de harde schijf wordt opgeslagen, en een Linux-pipe, wat een databuffer in het geheugen is die als een bestand is te gebruiken.

"Simpel gezegd, als je een pipe hebt waar je naar toe kunt schrijven en een bestand waarvan niet, dan kan het schrijven naar het geheugenbuffer van de pipe onbedoeld ook de gecachte pagina's van verschillende delen van het schijfbestand aanpassen", zegt beveiligingsexpert Paul Ducklin van Sophos. Hierdoor wordt de aangepaste cachebuffer door de kernel terug naar de schijf geschreven en de inhoud van het opgeslagen bestand permanent aangepast, ongeachte de permissies van het bestand.

Een lokale gebruiker kan zo een SSH-key aan het root-account toevoegen, een rootshell aanmaken of een cronjob toevoegen die als backdoor draait en een nieuw gebruikersaccount met rootrechten toevoegt. 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. Het probleem is verholpen in Linux 5.16.11, 5.15.25 en 5.10.102. Google heeft inmiddels een oplossing aan de Androidkernel toegevoegd. De impact van het lek is op een schaal van 1 tot en met 10 beoordeeld met een 7.8.

Reacties (47)
10-03-2022, 12:18 door Anoniem
Is dit alleen bij de Linux kernel het geval of bij ieder Nix achting systeem?.
10-03-2022, 14:17 door Anoniem
Door Anoniem: 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?
10-03-2022, 14:18 door Anoniem
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.
10-03-2022, 14:59 door autostatic
Geldt alleen voor Linux kernels vanaf 5.8, andere *nix besturingssystemen zijn niet kwetsbaar.
10-03-2022, 15:01 door Anoniem
Door autostatic: 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.
10-03-2022, 15:29 door Anoniem
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?
10-03-2022, 16:04 door Anoniem
Door Redactie: Een lokale gebruiker kan zo een SSH-key aan het root-account toevoegen, een rootshell aanmaken of een cronjob toevoegen die als backdoor draait en een nieuw gebruikersaccount met rootrechten toevoegt.

Even worse...

... it seems that this bug, given its low-level nature, can be used inside a virtualised container (where any running program is not supposed to have write access to any objects outside its “sandbox” or “jail”) to modify files that would usually be off limits.

https://nakedsecurity.sophos.com/2022/03/08/dirty-pipe-linux-kernel-bug-lets-anyone-to-write-to-any-file/
10-03-2022, 16:31 door Anoniem
Door Anoniem: 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.
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.
10-03-2022, 16:40 door _R0N_
Door Anoniem: 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.

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.
10-03-2022, 16:43 door _R0N_
Door Anoniem: 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?

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.
10-03-2022, 16:52 door autostatic
Door Anoniem:
Door autostatic: 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.
RHEL 8 zit op 4.18. Die is niet kwetsbaar.
10-03-2022, 17:04 door autostatic
Door Anoniem: 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?
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.
10-03-2022, 17:07 door autostatic
Door Anoniem: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.
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.
10-03-2022, 17:15 door Anoniem
Door autostatic:
Door Anoniem:
Door autostatic: 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.
RHEL 8 zit op 4.18. Die is niet kwetsbaar.
Redhat RHEL7 ook niet. 8 wel maar daar werken de exploits niet.
10-03-2022, 17:19 door Anoniem
Door autostatic:
Door Anoniem: 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?
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.
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.
10-03-2022, 17:32 door Anoniem
Door Anoniem: 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?
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.
10-03-2022, 19:14 door Anoniem
Door Anoniem: [..] 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.[...]
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.
10-03-2022, 19:38 door Anoniem
Door Anoniem:
Door Anoniem: 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.
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.
Weet jij dan, hoelang dit probleem bestond voordat het gepatcht werd en openbaar gemaakt werdt?
10-03-2022, 19:45 door autostatic
Door Anoniem: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.
Klopt, je hebt helemaal gelijk, ik ging te scherp door de bocht. Bedankt voor de opheldering!
10-03-2022, 20:56 door Anoniem
Door Anoniem: 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.

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.
10-03-2022, 22:34 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem: 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.
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.
Weet jij dan, hoelang dit probleem bestond voordat het gepatcht werd en openbaar gemaakt werdt?

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 .
10-03-2022, 23:48 door Anoniem
Door Anoniem:
Door Anoniem: [..] 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.[...]
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.
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.
11-03-2022, 05:59 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem: [..] 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.[...]
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.
Hint: citeer het deel waarover je reactie gaat, en niet van alles eromheen. Dat maakt je reactie een stuk duidelijker.
... 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.
11-03-2022, 08:01 door Anoniem
Door Anoniem:
Door Anoniem: 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.

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.

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


;-)
11-03-2022, 08:05 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem: 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.
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.
Weet jij dan, hoelang dit probleem bestond voordat het gepatcht werd en openbaar gemaakt werdt?

Openbaar 20 feb, de eerste patches 23 feb.
11-03-2022, 11:59 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem:
Door Anoniem: 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.
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.
Weet jij dan, hoelang dit probleem bestond voordat het gepatcht werd en openbaar gemaakt werdt?

Openbaar 20 feb, de eerste patches 23 feb.

Beter lezen, beter antwoorden.

zie 10 mar 22:34
11-03-2022, 12:21 door Anoniem
Door Anoniem: Weet jij dan, hoelang dit probleem bestond voordat het gepatcht werd en openbaar gemaakt werdt?

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

This bug suddenly became critical in Linux 5.8 with commit f6dd975583bd “pipe: merge anon_pipe_buf*_ops”.


De bug werd gerapporteerd op 20 februari 2022.

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

2021-04-29: first support ticket about file corruption
2022-02-19: file corruption problem identified as Linux kernel bug, which turned out to be an exploitable vulnerability
2022-02-20: bug report, exploit and patch sent to the Linux kernel security team
2022-02-21: bug reproduced on Google Pixel 6; bug report sent to the Android Security Team
2022-02-21: patch sent to LKML (without vulnerability details) as suggested by Linus Torvalds, Willy Tarreau and ...
2022-02-23: Linux stable releases with my bug fix (5.16.11, 5.15.25, 5.10.102)
2022-02-24: Google merges my bug fix into the Android kernel
2022-02-28: notified the linux-distros mailing list
2022-03-07: public disclosure

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.
11-03-2022, 14:19 door Anoniem
Door Anoniem: De bug ontstond en werd kritiek op 20 mei 2020, zo valt uit de rapportage van Max Kellermann op te maken:

Dat klopt, maar de Linux 5.8 kernel kwam pas op 2 augustus 2020 uit. Dat scheelt weer 2,5 maand aan logs analyseren.
11-03-2022, 14:38 door Anoniem
Door Anoniem:
In een professionele Linux werkomgeving werd de bug dus gerepareerd ruim voordat deze publiekelijk werd.
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.
11-03-2022, 20:46 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem:
Door Anoniem:
Door Anoniem: 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.
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.
Weet jij dan, hoelang dit probleem bestond voordat het gepatcht werd en openbaar gemaakt werdt?

Openbaar 20 feb, de eerste patches 23 feb.

Beter lezen, beter antwoorden.

zie 10 mar 22:34

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.
12-03-2022, 10:10 door S.A.T.A.N.
Door Anoniem: 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?
12-03-2022, 16:34 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem:
Door Anoniem:
Door Anoniem:
Door Anoniem: 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.
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.
Weet jij dan, hoelang dit probleem bestond voordat het gepatcht werd en openbaar gemaakt werdt?

Openbaar 20 feb, de eerste patches 23 feb.

Beter lezen, beter antwoorden.

zie 10 mar 22:34

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.

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 .
12-03-2022, 16:38 door Anoniem
Door S.A.T.A.N.:
Door Anoniem: 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?
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
13-03-2022, 09:16 door Anoniem
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.
13-03-2022, 09:37 door Anoniem
Door Anoniem:
Door S.A.T.A.N.:
Door Anoniem: 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?
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
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.
13-03-2022, 17:34 door Anoniem
Door Anoniem:
Door Anoniem:
Door S.A.T.A.N.:
Door Anoniem: 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?
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
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!
13-03-2022, 19:22 door Anoniem
Door Anoniem: 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.

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.
13-03-2022, 19:49 door Anoniem
Door Anoniem: Snel gefixt? Duurde bijna 2 jaar!

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.
13-03-2022, 20:42 door Anoniem
Door Anoniem:
Door Anoniem: Snel gefixt? Duurde bijna 2 jaar!

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.
13-03-2022, 21:10 door Anoniem
Door Anoniem:
Door Anoniem: 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.

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.

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.
13-03-2022, 21:41 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem: Snel gefixt? Duurde bijna 2 jaar!

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.
Dat is het resultaat van zo lang lek zijn. En dan ben je nog blij ook. Rare jongens, die Linux fans.
13-03-2022, 21:58 door Anoniem
Door Anoniem:
Door Anoniem: 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.

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.

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.
14-03-2022, 11:26 door SPer
Wet 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.

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.
14-03-2022, 14:25 door botbot - Bijgewerkt: 14-03-2022, 14:26
Door Anoniem: 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.

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?
14-03-2022, 14:29 door botbot
Door Anoniem: 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?

Weet jij hoeveel gebruikers bij een hosting partij zitten? 20.000 tot 50.000 op een shared cluster?
14-03-2022, 14:46 door Anoniem
Door botbot:
Door Anoniem: 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?

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
15-03-2022, 08:09 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem:
Door Anoniem: Snel gefixt? Duurde bijna 2 jaar!

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.
Dat is het resultaat van zo lang lek zijn. En dan ben je nog blij ook. Rare jongens, die Linux fans.
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.
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.