Stack Clash-kwetsbaarheid geeft roottoegang op Unix-systemen

Beveiligingsbedrijf Qualys waarschuwt voor een lek in verschillende systemen, waaronder Linux, OpenBSD, NetBSD, FreeBSD en Solaris. Door een lek in het geheugenmanagement is het mogelijk om roottoegang te verkrijgen als er al toegang tot het systeem bestaat.

Qualys meldt dat het zich gericht heeft op de lokale toepassing van exploits voor het lek en dat het daarom niet kan zeggen of het ook op afstand te gebruiken is. Het bedrijf kan dit echter niet volledig uitsluiten, omdat het gebruik op afstand afhankelijk is van verschillende applicaties. Zo was het gebruik op afstand in de Exim-mailserver bijvoorbeeld niet mogelijk, maar Qualys schrijft dat toe aan toeval. Het privilege escalation-lek, met kenmerk CVE-2017-1000364, werkt op zowel i386- als amd64-systemen. Het bedrijf heeft met verschillende partijen samengewerkt om oplossingen te ontwikkelen.

De methode achter de kwetsbaarheid, die van Qualys de naam Stack Clash heeft gekregen, is niet nieuw. In 2005 presenteerde onderzoeker Gaël Delalleau al een aanval die van Stack Clash gebruikmaakte. De methode gebruikt het feit dat geheugen, in de vorm van de stack, 'naar beneden' groeit als een proces meer geheugen nodig heeft. Daardoor kan bijvoorbeeld een conflict ontstaan met de zogenaamde heap, die op zijn beurt 'omhoog' groeit.

Door dit conflict te benutten is het mogelijk om een bepaald geheugenbereik te overschrijven. Het Qualys-onderzoek toont aan dat deze methode nog steeds werkt, ondanks de bescherming die door middel van een guard page werd geïntroduceerd. De Qualys-methode maakt het in feite mogelijk om over de guard page 'heen te springen'.

Het beveiligingsbedrijf heeft verschillende poc's ontwikkeld. Zoals eerder genoemd deed het dit voor de Exim-mailserver, maar ook voor sudo en ld.so. Qualys maakt de exploits en poc's niet openbaar, dat wil het pas doen als voldoende tijd is verstreken. Het heeft sinds mei samengewerkt met de getroffen bedrijven en schrijft dat er inmiddels patches beschikbaar zijn. Het is daarom aan te raden een update uit te voeren. Onder meer Red Hat heeft een advisory gepubliceerd.

Reacties (57)

[fameus]

Ik word niet erg gerust van de RedHat advisory.
De enige wijziging op kernel niveau is de vergroting van de guard page.
Het tweede deel, de aanpassing van glibc, is toch niet af te dwingen?
Wat houdt me tegen om iets statisch te linken met een "foute" glibc?
Sowieso: hoe kun je een kernel vulnerability repareren door de userland kant aan te passen?

[Reactie gewijzigd door fameus op 24 juli 2024 21:33]

[GertMenkel]

Het probleem dat hier speelt is de manier waarop applicaties met geheugen werken.

In het geheugen van een proces groeit de stack omlaag en de heap omhoog. Op een gegeven moment kunnen die elkaar tegenkomen. Dan kun je op een gegeven moment met heap data gaan schrijven naar de stack en je eigen code laten uitvoeren en als dat werkt kun je vanuit het aangevallen proces narigheid uithalen.

De guard page is bedoeld om dit te voorkomen, maar die was in dit geval te klein gemaakt om effectief alle crashes op te vangen.

Je kunt veel applicaties patchen door glibc aan te pakken aangezien de geheugenfuncties (malloc en dergelijke) hier een grote rol in spelen. Als het goed is dan zullen de applicaties hier niets van merken, maar zal het het risico van (bijna) alle exploits minimaliseren.

Dit is een exploit die zich richt op een bestaand proces of bestaande executable die je niet kunt aanpassen, alleen uitvoeren. Natuurlijk kun je je eigen libc statisch linken, maar je statisch gelinkte executable heeft geen rechten die je nog niet had dus je hebt er weinig aan.

Als je niet geeft om root en alleen code wilt uitvoeren op een target dan heb je ook weinig aan je statisch gelinkte executable: uitvoeren van je executable is nou juist je doel, niet je middel.

Dit is eigenlijk een oude methode met een nieuwe verpakking; het is de oude exploitmethode met een trucje om de mitigatie van de vorige patches tegen te gaan.

[H!GHGuY]

Sowieso: hoe kun je een kernel vulnerability repareren door de userland kant aan te passen?

Aangezien nog niemand echt deze vraag beantwoordt heeft:

- de alloca() functie (die geheugen op de stack alloceert) kan aangepast worden om elke op elke page (typisch 4kB) minstens 1 byte te schrijven. Zo zal de guard page (zelfs al is ze maar 4kB) beschreven worden en een crash veroorzaken.
- de compiler kan hetzelfde doen als een functie een grote hoeveelheid geheugen op de stack alloceert. Nu al kun je o.a. GCC vragen om een warning te geven als een functie grote hoeveelheden data alloceert, dus de kennis is beschikbaar. Als ze op dat moment ook nog enkele writes in de code zouden stoppen zou dit ook een crash veroorzaken.

De performance impact hiervan zal niet zo groot zijn. Functies die grote hoeveelheden alloceren op de stack zijn uitzonderlijk. Anderzijds zal dit minstens 1 of meer TLB misses veroorzaken, hoewel als de gealloceerde data structuur niet sparse was zou je die sowieso gehad hebben. Idem ditto met de data caches waar je enkele cache lines bevuilt.

[VoDkA12]

Inderdaad, guard page in kernel vergroot naar 1MB.

Een aantal packages moeten nog herbouwt worden (met gcc -fstack-check):

"To avoid stack guard page jumping, every stack allocation primitive needs to implement freshly allocated memory probing with the stack guard gap size granularity. The existing gcc -fstack-check implementation aims to do exactly that, but currently it is not working correctly. Before the gcc -fstack-check implementation is fixed and all of the exposed binaries are rebuilt,"

[rvt1]

Wat houdt me tegen om iets statisch te linken met een "foute" glibc?

Niets!
Echter zijn er wel vele distributies die eisen dat een makefile ook niet statisch linkt maar dynamisch. Zelf ben ik alleen bekend met Debian en die eist van ons dat LibreCAD's makefile dat dus dynamisch linkt. Dat geld dan voor alle libraries en niet alleen glibc. Er zijn wat uitzonderingen maar dan moet je wel moet goede rede aankomen kloppen.

ALs je zelf dus compileert dan houdt je het niet tegen, maar dan ook niet zelf zeuren als je gehackt wordt op jouw statisch gelinkt applicatie. Wat je dus zelf het beste kunt doen als je er weinig van weet is niet lopen klooien op productie systemen maar dat aan professioneels overlaten.

Sowieso: hoe kun je een kernel vulnerability repareren door de userland kant aan te passen?

1) C library described in ANSI,c99,c11 standards. It includes macros, symbols, function implementations etc.(printf(),malloc() etc)

2) POSIX standard library. The "userland" glue of system calls. (open(),read() etc. Actually glibc does not "implement" system calls. kernel does it. But glibc provides the user land interface to the services provided by kernel so that user application can use a system call just like a ordinary function.

3) Also some nonstandard but usefull stuffs.
via : https://stackoverflow.com...glibc-what-is-it-used-for

[fameus]

OK, ik had de functie van glibc niet helemaal door.
Ik bedoelde overigens: een exploit programma maken dat statisch gelinkt is met een "foute" glibc. Maar dat kan dus niet als ik het goed begrijp.

[Jeanpaul145]

Kan ik uit je reactie afleiden dat programma's die in bv Go zijn geschreven dan categorisch geweigerd worden door de Debian maintainers? Want in Go-land is alles is statisch gelinkt, en dat is by design.

[rvt1]

Durf ik niet te zeggen. Ik heb geen ervaring met Go en Debian wat dat betreft.

maar als Go applicaties statisch compileren tegen bekende libraries die Debian mee levert dan kunnen ze wel een uitzondering maken omdat het wellicht niet anders kan met Go.

[MSalters]

Sowieso: hoe kun je een kernel vulnerability repareren door de userland kant aan te passen?

Het bestaan van een heap is geen echte kernel-zaak. Hoe een applicatie z'n geheugen regelt is vooral een zaak van die applicatie. In het bijzonder is de heap van een modern Java proces geschikt voor Garbage Colelction en opgedeeld in generaties.

De stack is iets "echter" omdat je op hardware nivo een stack pointer hebt.

Een proces wat door deze clash gecorrumpeerd wordt kann op kernel nivo geen extra schade aanrichten - het kan niets meer dan het daarvoor kon. Het risico zit'm dus in domme configuraties die internet-exposed services als root draaien.

[rvt1]

Sowieso: hoe kun je een kernel vulnerability repareren door de userland kant aan te passen?

Dit is niet zo zeer het repareren van iets...

Met deze methode kun je niet privilege escalation doen. Mocht je dus er doorheen komen, heb je dezelfde permissies. Het is dus niet zo dat jij een een applicatie onder jouw eigen user kan draaien en opeens root kan worden.
Dit wordt natuurlijk iets gevaarlijker als je een daemon onder root hebt draaien die je wel op deze manier kan exploiteren. (Dit is ook de reden dat je daemon as root probeert te vermijden).

Er is wel een methode om het tijdens compileren -fstack-check zie: https://gcc.gnu.org/onlinedocs/gccint/Stack-Checking.html

[P1nGu1n]

Is Android ook kwetsbaar?

Edit:
Volgens Ars Technica is dat nog niet duidelijk:

A Qualys representative told Ars that company researchers worked with developers of FreeBSD, NetBSD, OpenBSD, Solaris, and the main Linux distributions including Red Hat and SuSE, Debian, and Ubuntu. The representative said company researchers didn't research Microsoft or Apple products, but that they did contact both companies beforehand so they could investigate. The effect the vulnerability may have on Google's Android mobile OS is not clear.

[Reactie gewijzigd door P1nGu1n op 24 juli 2024 21:33]

[DCK]

Het zal zeer waarschijnlijk werken voor Android op x86-apparaten - maar dat zijn er niet zoveel. Asus en LG hebben ooit wat telefoons uitgebracht met een x86-chip, de Nexus Player draait Android op x86, en er zijn wat Chinese tablets die Android op een Atom-chip draaien. M.u.v. de Nexus Player worden al deze apparaten toch niet meer gepatcht en zijn daarmee al kwetsbaar voor de Dirty C0w privilege escalation exploit van oktober vorig jaar. Deze kwetsbaarheid verandert dus niet heel veel aan het verhaal.

Het is zeer twijfelachtig dat dit zomaar werkt op ARM-systemen. Mechanismen omtrent geheugenallocatie kunnen zeer architectuurafhankelijk zijn, en daarom zal de exploit sowieso niet 1-op-1 werken op ARM. Het is zelfs te verwachten dat dit gebruik maakt van een mechanisme op x86 dat in zijn geheel niet op ARM van toepassing is. Maar daar wordt ongetwijfeld verder naar gekeken.

Mocht deze kwetsbaarheid voor ARM-platformen werken, dan zal er ook ongetwijfeld een andere CVE voor worden gepubliceerd.

[Reactie gewijzigd door DCK op 24 juli 2024 21:33]

[MSalters]

Het is zeer twijfelachtig dat dit zomaar werkt op ARM-systemen. Het is zelfs te verwachten dat dit gebruik maakt van een mechanisme op x86 dat in zijn geheel niet op ARM van toepassing is.

De bug bestaat gewoon op ARM systemen zoals een Raspberry Pi.

Logisch. Stack en heap zijn compleet standaard mechanismes.

[DCK]

Hm. Het feit dat Ubuntu dezelfde patch voor ARM uitbrengt wil niet op zichzelf zeggen dat ARM ook écht kwetsbaar is. Ik wil best geloven dat dit op ARM exploiteerbaar is, maar het feit dat dezelfde patch als op AMD64 wordt meegenomen kan ook een voorzorgsmaatregel of overgenomen/gesynchroniseerde configuratie (omvang van guard pages) zijn.

[Reactie gewijzigd door DCK op 24 juli 2024 21:33]

[tweaknico]

Is helemaal niet logisch..., er zijn platformen waarbij de afstand tussen stack top en heap top zodanig ver uit elkaar liggen dat het theoretisch wel kan, maar praktisch wel lastig wordt. [ bv. 512MB geheugen aanwezig, en afstand tussen stack top en heap top 1GB.... ]

VAX heeft een ander mechaniek:
Voor memory management wordt een adres op de stack (herkenbaar aan adres reeks) gecontroleerd tegen een stack-limit register, en een reguliere data access aan een base-limit register.
Hier zijn geen guard pages nodig als bescherming. Als een adres in de 1e 1GB memory zit is het Base memory, de 2e 1GB memory is stack, het blijft gescheiden.

Daarnaast een OS als bv. OpenVMS heeft gewoon meerdere stacks beschikbaar, 1 voor interrupts, 1 voor Kernel(device & memory management), 1 voor Executive mode(IO systeem), 1 voor Supervisor mode(CLI), 1 voor Usermode (jouw code).
Dus het overschrijven van de Usermode stack (en dat kan je zo wie zo), levert je vermoedelijk een process abort van je software op. Vanuit usermode kun je de andere stacks niet eens bekijken.

[MSalters]

Is helemaal niet logisch..., er zijn platformen waarbij de afstand tussen stack top en heap top zodanig ver uit elkaar liggen dat het theoretisch wel kan, maar praktisch wel lastig wordt. [ bv. 512MB geheugen aanwezig, en afstand tussen stack top en heap top 1GB.... ]

Is geen fundamenteel probleem voor deze Stack Clash aanvallen. De guard page buffer is een stuk ongealloceerd geheugen tussen heap en stack, maar het nieuwe van deze aanval is dat ze die guard page kunnen skippen.

En omdat Linux een allocate on access doet, heb je helemaal geen 1 GB ram nodig om een afstand van 1 GB tussen heap en stack te overbruggen. De alloca() call van 1 GB gebruikt misschien 4 kb ram, en overlapt dan al de heap.

[tweaknico]

Allocate on Access heeft nog steeds een ingevulde pagetable nodig. (Moet dus ook gevolgen hebben voor de reservering van pagefile ruimte etc.
Afhankelijk van de keuze van de kernel page allocator, zou stack expansion tot 4K pages nodig hebben voor de 256K PTE's voor 1GB of stack space. (4K pages).
Of ten minste een reorganisatie van de pagetables naar een andere page groote, maar de wordt de footprint ook gelijk groter dan die 4K.

De fout is dan primair dat alloca() niet controleert op geheugen overschijding, de implementatie kan ook en happen van pagesize de pages even aanraken.
Maar ja, safety en security is altijd al een kwestie geweest van afterthought, if any thought at all.

[MSalters]

Waarom zou je een page table entry nodig hebben? Je proces segfault, Linux krijgt een interrupt van je CPU, en de page table entry on-demand aanmaken.

[tweaknico]

SegFault != pagefault. Segfault is niet toegestane access op geheugen doen.
Als Segfault op die manier wordt ingevuld tja dan is dat een design wat vraagt om ongelukken.

Paging kan alleen efficient worden uitgevoerd als je op een zeer laag niveau (PageFault, = interrupt handler) niet de rest van het systeem hoeft te blokkeren op zoek naar een stukje geheugen om een setje PTE's aan te maken.
De de Pagetables aanmaken en invullen zodra dat kan. Dat er een PageNot Present bit aanstaat, tja dat kan een pagefault handler oplossen door de juiste page van een Demand zero page te voorzien dan wel een van de free list/ pagefile te (laten) halen.

[borft]

in het artikel staat i386 en amd64. Meeste Android devices zijn ARM. Dus het is nog niet aangetoond. Maar er wordt ook aangegeven dat andere hardware platforms niet getest zijn. Kortom, we weten het niet

[GertMenkel]

Het lijkt erop dat we op ARM misschien geluk hebben zolang de officiële compiler is gebruikt en of andere slimmert niet stom heeft lopen doen om wat kilobytes te besparen:

Stack and heap collision detection

By default, if memory allocated for the heap is destined to overlap with memory that lies in close proximity with the stack, the potential collision of heap and stack is automatically detected and the requested heap allocation fails. If you do not require this automatic collision detection, you can save a small amount of code size by disabling it with #pragma import __use_two_region_memory.
Note:
The memory allocation functions (malloc(), realloc(), calloc(), posix_memalign()) attempt to detect allocations that collide with the current stack pointer. Such detection cannot be guaranteed to always be successful.

http://infocenter.arm.com...75m/chr1358938929242.html

Dit gaat er overigens wel van uit dat de standaardcompiler van ARM wordt gebruikt. In GCC werkt de check (zoals in het artikel staat) niet goed, dus Androidversies die met GCC worden gecompileerd hebben dit probleem waarschijnlijk ook.

[- peter -]

Android gebruikt GCC en is bezig met de overstap naar CLANG

[GertMenkel]

Oh dat wist ik niet, bedankt voor het corrigeren

[MSalters]

Dat hangt af van de precieze explot. Stap 1 van deze exploit is om de twee areas te laten botsen, en dat kan op twee manieren: de heap laten groeien, of de stack. malloc() kan de stack wel vermijden, maar de stack groeit in precies 1 richting. Daar zit geen beleid achter.

Eén van de gebruikte exploits is een qsort() routine die worst-case N/4 recursieve calls gebruikt als je N data items sorteert. Dat is daarmee een effectieve manier om de stack te laten groeien, en indien de data onder controle van de attacker is dan kan de ARM compiler daar niets aan doen.

[GertMenkel]

De compiler kan code genereren die voor het uitbreiden van de stack controleert of er nog voldoende ruimte tussen de stack en de heap is. Het is en blijft code die geheugen reserveert voor de stack, hoe low level die code ook mag zijn. Een aangevallen programma zal in zo'n geval waarschijnlijk crashen met een SIGSEV oid omdat het OS weigert de stack uit te breiden. In ieder geval stukken beter dan een root exploit zou ik zeggen.

Dit alles gaat natuurlijk wel ten koste van snelheid, het ligt er maar net aan wat je belangrijk vindt.

[Verwijderd]

Ik kan dan toch nog steeds een binary maken die met mijn eigen soort compiler is gemaakt?

Ik geloof dat de oplossing hier is om een nieuwe glibc te gebruiken die verbeterde alloca en malloc implementeren. Niet echt andere compilers.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 21:33]

[MSalters]

alloca is de facto geen glibc functie; de compiler kan dat inlinen.

[GertMenkel]

Dat kan zeker. Het gevolg daarvan: de applicatie die je maakt is dan zelf kwetsbaar
Het gaat er hier om dat je een exploit uitvoert op een programma dat je niet zelf compilet; je exploit een bestaand programma waar je geen controle over hebt.

Als je zelf een binary maakt en die uitvoert kun je net zo goed meteen je system("rm -r -f --no-preserve-root /") in je code stoppen, scheelt je een hoop werk.

[H!GHGuY]

De documentatie zegt ook nog dit:

Note:
The memory allocation functions (malloc(), realloc(), calloc(), posix_memalign()) attempt to detect allocations that collide with the current stack pointer. Such detection cannot be guaranteed to always be successful.

Although it is possible to automatically detect expansion of the heap into the stack, it is not possible to automatically detect expansion of the stack into heap memory.

In een multi-threaded programma ben je dus al de sjaak, want daar laat je een andere thread met stack pointer ver weg van de heap de allocatie doen. Bovendien is de exploit net omgekeerd: de stack overflowt op de heap. Je bent dus dubbel de sjaak want deze bescherming helpt weinig.

Daarenboven is niet gespecifieerd wat "close proximity" betekent. In Linux is de default stack size 8MB, dus als ze dit in de exploits al overwinnen, is het wsch ook mogelijk om vroeg een memory allocatie te triggeren (die deze bescherming niet triggert) en daarna pas het nodige doen om de stack te laten groeien.

Er zijn waarschijnlijk wel gevallen waarin het iets kan doen, maar ik vermoed dat die de minderheid vormen.

[SpoekGTi]

Wel fijn dat Synology het al gepatched heeft. https://www.synology.com/nl-nl/support/security

Alleen nu nog de uitrol, maar goed die zal niet lang op zich laten wachten.

[devil-strike]

Er staat helemaal niet dat er gepatched is, er staat dat er aan gewerkt word, en dus nog niet tedownloaden is.

[SpoekGTi]

Nee er staat letterlijk dat ze geen vulnarbilitys naar buiten brengen als er nog geen middelen zijn die het probleem op lossen.

[Titan_Fox]

Misschien dat het hiermee lukt om de Playstation 4 te hacken ? Die draait volgens mij op een afgeleide van FreeBSD.

[Tribits]

Zal je er eerst alsnog in moeten slagen om unsigned code op de PS4 te draaien. Kip en ei verhaal.

[svennd]

Maar dat kan met een userland exploit neem ik aan ? (zoals in games)

[batjes]

Al die games en software is gesigned.

Alle software en games die je op de PS4 kan draaien, zijn grondig door Sony nagelopen of deze zich aan de specificaties en eisen van Sony voldoen. Je krijgt niets op die console wat niet door Sony goedgekeurd is.

[innerchild]

En de browser dan op de ps4 ? Hiermee kan je naar website gaan die jezelf hebt opgezet en dan met allerlei exploits proberen een gaatje te vinden.

[batjes]

Is mogelijk, maar Sony is ondanks hun enorme security breuk een paar jaar geleden met PSN, niet zo heel erg slecht met het dichttimmeren van hun spul. De PSX en PS2 harden hardware hacks nodig en de PS3 heeft zich vele jaren standgehouden terwijl de 360 revisie naar revisie door moest om de boel dicht te blijven timmeren (en MS is ook geen groentje betreft security, ondanks de bedenkingen die men heeft met Windows).

Nu zal er vast wel wat te kloten zijn via de browser, maar unsigned code laten draaien zal uiterst lastig zijn. Ik gok een beetje dat het met enkel een software hack, niet eens mogelijk zal zijn en dat ze het ergens hardwarematig ook beveiligd hebben.

Alles kan gehacked worden en wat gemaakt wordt door mensen, kan altijd gesloopt worden door mensen.

[SuperDre]

De PS3 is een tijd lang hackable geweest mits je maar een bepaalde range firmware en model had. De laatste incarnatie van de slim (CECH3xxx) en de superslim (laatste model) zijn nog steeds niet gekraakt.

[RangedNeedles]

Via allerhande exploits in WebKit (die Sony altijd te laat patcht), kan je ondertussen dacht ik wel usermode applicaties draaien. Als je dan van deze kwetsbaarheid gebruik kan maken, zit je volgens mij wel goed

[MaxTheKing]

Hopen dat pfSense dit ook snel oplost

[Maurits van Baerle]

Het zit op een dermate laag niveau dat ik denk dat pfSense dit door developers van (het onderliggende) FreeBSD laat oplossen.

Ik zou deze thread even in de gaten houden: https://lists.freebsd.org...ity/2017-June/009328.html

[DennusB]

Tijd om wat systemen te patchen!

[Ed Vertijsment]

Ik wacht wel op het mailtje van unatrended upgrades

[wica]

vergeet niet te reboten, de update installeren alleen is alles behalve voldoende.

[mrdemc]

Hangt helemaal van je implementatie af toch? Is dat niet wat KernelCare bijv. voorkomt?

[wica]

Kende KernelCare niet, maar dat kost geld per maand per server. Dan liever iets als kexec.

Maar door dat hij zei: "unattended upgrade" ga ik er vanuit dat die Debian/Ubuntu gebruikt en dus niet de mogelijkheid heeft om de kernel op wat voor manier, te hot patchen.

En dan is een reboot toch echt wel noodzakelijk.

[mrdemc]

Lijkt me wel inderdaad als het gaat over die specifieke functie. In het geval van CentOS / Cloudlinux ken je inderdaad geen unattended upgrade, wel de update dus snap dat je die conclusie trekt. Ik las zelf over het woordje upgrade heen

[wica]

Klopt Fedora en CentOS hebben er voor gekozen, bij een update het hele systeem te herstarten.
Om te voorkomen, dat er o.a. verouderde lib's inhet geheugen blijven.

Persoonlijk vind ik dit niet de linux manier, van updaten en moet ik persoonlijk denken aan windows.


/edit typos

[Reactie gewijzigd door wica op 24 juli 2024 21:33]

[Dorank]

Er is weinig keuze, het probleem zit ook in libc (CVE-2017-1000366). De enige manier om zeker te zijn is dus echt alle processes te herstarten (ook het init process (tenzij iemand kan bewijzen dat telinit u altijd werkt))

[svennd]

Red Hat heeft gekozen voor die methode, CentOS en Fedora zijn afgeleid daarvan ...

[Balachmar]

Voor Ubuntu kun je dat tegenwoordig wel degelijk doen:
https://insights.ubuntu.c...now-available-for-ubuntu/

Ik draai het zelf ook.

[sfranken]

Ubuntu kun je tegenwoordig prima "hot patchen" hoor: https://insights.ubuntu.c...now-available-for-ubuntu/

Edit: te laat..

[Reactie gewijzigd door sfranken op 24 juli 2024 21:33]

[Ed Vertijsment]

No worries, auto reboot if required

[Jaded]

Voor de mensen die ook Cloudlinux en Kernelcare gebruiken, zoals geverifieerd met support:
Kernelcare patches komen bijna uit. Daarnaast glibc updaten. Reboot is niet nodig.

[MeMoRy]

Waar baseer je dat op?