Onderzoekers ontdekken grote kwetsbaarheid in Linux-kernel

Onderzoekers aan de Universiteit van Graz in Oostenrijk hebben een grote kwetsbaarheid ontdekt in de Linux-kernel. De aanvalstechniek, bekend als een cross-cacheaanval, geeft aanvallers willekeurige lees- en schrijfopties.

De onderzoekers hebben vastgesteld dat de kwetsbaarheid aanwezig is in de Linux-kernels v5.19 en v6.2. Deze versies zijn vatbaar voor negen verschillende CVE-kwetsbaarheden, op virtuele machines van zowel 32bit als 64bit. De aanval is ook effectief wanneer geavanceerde verdedigingsmethoden worden gebruikt, zoals Supervisor Mode Execution Prevention, Supervisor Mode Access Prevention en Kernel Address Space Layout Randomization.

Door gebruik te maken van een beperkte heapkwetsbaarheid kunnen aanvallers lees- en schrijfacties uitvoeren. Dit stelt hen in staat om toegangsrechten te verhogen of uit beveiligde omgevingen te ontsnappen. De aanval maakt misbruik van de manier waarop Linux geheugen beheert. De recent ontdekte methode, SLUBStick genaamd, heeft een slagingspercentage van 99 procent. Dit wordt mogelijk gemaakt door een techniek die het precieze moment van geheugentoewijzing identificeert. Daardoor kunnen aanvallers op het hergebruik van geheugen anticiperen en kunnen ze dit hergebruik manipuleren.

Reacties (61)

[The Zep Man]

Kernels 5.19 en 6.2 worden niet meer ondersteund en zijn geen longterm releases. De kwetsbaarheid is groot, maar het zal 'as-is' beperkt toegepast kunnen worden omdat weinig systemen van deze kernels gebruik maken.

[edit]
T.net noemt 5.9, maar de bron noemt 5.19. Reactie gecorrigeerd.

Verdere uitleg, code en demonstraties vind je hier. De videos laten zien dat het niet nodig is om rootrechten te hebben, en dat het met drie varianten van de aanval mogelijk is voor een gewone gebruiker om op dezelfde machine rootrechten te verkrijgen.

Zoals genoemd is de kwetsbaarheid groot, maar de impact hoeft niet groot te zijn. Een volwassen organisatie is voorbereid op de mogelijkheid tot local privilege escalation. In het verleden zijn voldoende van zulke kwetsbaarheden uitgekomen om te weten dat dit nooit volledig uit te sluiten is. Men moet ondertussen geleerd hebben om niet op een enkele laag beveiliging te vertrouwen.

[Reactie gewijzigd door The Zep Man op 6 augustus 2024 09:29]

[EnigmA-X]

Kernels 5.19 en 6.2 worden niet meer ondersteund en zijn geen longterm releases. De kwetsbaarheid is groot, maar het zal 'as-is' beperkt toegepast kunnen worden omdat weinig systemen van deze kernels gebruik maken.

Ubuntu 22.04.2 LTS is in februari 2023 gereleased op de 5,19 kernel
Ubuntu 22.04.3 LTS is in augustus 2023 gereleased op de 6.2 kernel
Ubuntu 22.04.4 LTS is nu current (voor 22.04) en draait pas sinds 20 februari 2024 op de 6.5 kernel

Kortom, Ubuntu 22.04.2 en .3 LTS (laatst deployed en upgraded tussen februari 2023-2024) zijn kwetsbaar.

Ik zou niet durven zeggen dat "weinig systemen van deze kernels gebruik maken". Ik denk eerlijk gezegd dat er nog wel wat systemen zijn die deze 22.04-releases draaien. Ik zie er iig nog genoeg op Shodan...

[Archcry]

Altijd weer leuk om een lijstje EOL kernels te zien staan. Weer typisch Ubuntu (Canonical) om hun LTS releases te baseren op EOL (eerst stable) kernels i.p.v. gewoon gebruik te maken van LTS kernels die door upstream gepatched worden. Zo zijn we wederom in de situatie beland waar elke Ubuntu server op het internet mogelijk kwetsbaar is voor deze exploit.

Ik weet dat Canonical deze kernels zelf patched maar kan iemand mij vertellen waarom? Waarom moet een LTS release van Canonical bij release altijd één van de laatste kernel versies bevatten? Ik snap dat dit voor hardware compatibility handig is maar zijn er dan echt zo veel servers die bleeding edge hardware hebben en persé de laatste kernel nodig hebben? Lijkt mij niet aangezien hardware over het algemeen ook aangeschaft wordt nadat deze "bewezen" is.

Mijn boodschap voor Canonical is dan ook: Stop alsjeblieft met het shippen van LTS releases met EOL (of soon to be EOL) kernels. Gebruik gewoon een LTS kernel waar je van Upstream patches ontvangt en ga niet zelf patches backporten naar een EOL kernel.

[Reactie gewijzigd door Archcry op 6 augustus 2024 12:52]

[GertMenkel]

Als Ubuntu "LTS" zegt, betekent dat tien jaar.

Als Linux "LTS" zegt, betekent dat drie tot zes jaar.

Er is geen "LTS-kernel waar je van upstream patches ontvangt" voor een LTS-distro als Ubuntu. Daarom doet Ubuntu dan ook HWE-updates; hierbij kun je dezelfde versie van Ubuntu blijven draaien met een nieuwere of oudere kernel.

Overigens onderhoudt Canonical zelf kernels (door middel van backports en dergelijke). De specifieke combinatie (Ubuntu 22.04.3 + Linux 6.2) is dan ook geen combinatie die LTS-support krijgt; daarvoor zul je naar een HWE-stack toe moeten. Linux 6.2 is mooi voor desktopgebruikers die van zelf naar 22.04.4 zijn geüpdatet, maar niet voor bedrijven die de boel lange termijn willen blijven gebruiken.

Wellicht zitten er nog mensen op verouderde, niet-HWE-stacks 22.04 te draaien, maar dat zouden ze niet moeten doen.

[Reactie gewijzigd door GertMenkel op 6 augustus 2024 15:27]

[rbr320]

Wat is niet begrijp is dat Canonical de wind van voren krijgt als ze zoiets doen, terwijl je er niemand over hoort dat aan de Enterprise Linux kant precies hetzelfde gebeurd. De kernel versie van Red Hat Enterprise Linux 9 en zijn afgeleiden (CentOS, Rocky, Alma, Oracle, etc) is 5.14, wat tussen de LTS kernels 5.10 en 5.15 in zit.

Als je het zo bekijkt doet van de grote distributies alleen Debian het goed. Debian 12 gebruikt LTS kernel versie 6.1, Debian 11 gebruikte 5.10 LTS die nog tot december 2026 wordt ondersteund en Debian 13 zal zeer waarschijnlijk gebaseerd worden op de volgende LTS kernel.

[Archcry]

Goede toevoeging wat mij betreft hoor. Ik vind inderdaad dat RHEL hier dan ook de wind van voren voor zou moeten krijgen. Ik denk dat de reden dat mensen snel aan Canonical en Ubuntu denken is omdat het sneller onderwerp van gesprek is. Ubuntu stond / staat natuurlijk bekend als "beginner friendly" linux distributie (hoewel ik hier al een hele tijd mijn vraagtekens bij zet). RHEL is vooral onderwerp van gesprek binnen de zakelijke wereld terwijl Ubuntu ook in de consumentenmarkt veel besproken wordt.

[rbr320]

Goede punten.

Wat betreft de kernel keuze voor Ubuntu of RHEL denk ik dat het meestal gewoon een kwestie van timing is. Op het moment dat de distributie wordt uitgebracht willen ze graag een redelijk nieuwe kernel aanbieden en dat komt niet altijd uit met wanneer het Linux kernel ontwikkelteam besluit een kernel tot LTS versie te verheffen.

Vergeet niet dat zowel Canonical als Red Hat al aardig wat eigen "out of tree" patches op hun kernel toepassen. Daarnaast gaat de ondersteuningsperiode van hun distributie vaak ruim over de ondersteuningsperiode van de LTS versies van de Linux kernel die op het moment van uitgave courant is heen. Dus waarschijnlijk nemen ze de moeite, tijd en geld die het kost om beveiligingspatches te backporten voor lief omdat het in de marge van wat ze toch al aan hun kernel versleutelen weg valt.

[anvil]

RedHat blijft gedurende de lifecycle dezelfde kernel gebruiken om zo compatibiliteit te garanderen , ook met exotischere hardware met speciale drivers etc alsmede 3rd party software.

Zo is bijvoorbeeld het Lustre filesysteem erg gevoelig voor gebruik van andere dan recommended versies van kernel en OFED en krijg je heel lastig te debuggen issues als je zelf gaat klooien buiten de compatibility matrix.

[kdekker]

Voor enterprise versies als SLES en RHEL weet ik wel een antwoord waarom dit een gebruikelijke gang van zaken is. Toen ik nog met die platformen werkte als software ontwikkelaar, valideerde je voor de major versies en de service pack releases. En daarom was het vrij logisch dat er geen major kernel versie omhoog gegaan wordt in een al verscheepte OS versie. Dat is een garantie van compatibiliteit (bijv ABI, libc).

Als een Linux distributie halverwege de route wel een major kernel update doet, dan moet je je software opnieuw valideren. Dat kost tijd en geld, of zelfs onmogelijk als je zelf een groot en complex softwarepakket maakt, waarvan de release cycli langzamer zijn dan Linux updates.

Nu moet ik er wel bij zeggen dat C/C++ compatibiliteit vrij weinig gebroken werd en kernel updates doorgaans weinig last gaven.

O ja: security updates veranderden bij SuSE of Redhat niet de major of 1e digit van de kernel, maar ergens de 3e of 4e decimaal, waar in principe ook compatibiliteit aanwezig zou moeten zijn.

[Reactie gewijzigd door kdekker op 6 augustus 2024 18:14]

[rbr320]

Wat je verteld ben ik me van bewust en klopt ook allemaal, maar het beantwoord niet de vraag van mij en
@Archcry waarom men Linux distributies met langdurige ondersteuning uit geeft zonder daarbij gebruik te maken van een kernel versie die vanuit het Linux kernel development team al langdurige ondersteuning geniet. Dat zou hun leven namelijk makkelijker maken, in ieder geval in de periode waarvoor die langdurige ondersteuning op de kernel geldt.

Ik geef echter in deze reactie al min of meer antwoord op die vraag en ook @GertMenkel maakt in deze reactie goede punten, maar toch blijft het bij mij ergens knagen dat men zichzelf werk kan besparen door meer met de upstream LTS kernels te werken.

[kdekker]

Dat zal vaak met timing te maken hebben, bij de Linux distributie maker.

Iig herken ik dat met toentertijd releasen van eigen software, waar je dan ook voor de keuze staat welke Linux versie je pakte voor validatie. In ons geval bijna altijd GA versies (ook omdat het beta traject qua tijd van een Linux distributie lang niet altijd bekend was en je eigen planning ook gehaald moet worden). Je eigen planning was vaak al complex genoeg.

[GertMenkel]

De beslissing welke kernel upstream LTS wordt, is niet altijd gemaakt voordat er een distro wordt gemaakt. 6.1 werd bijvoorbeeld pas in 2023 als LTS aangeduid. Toen was Ubuntu 22.04 al lang uit. Dat jaar werd de support lifecycle van upstream ook naar twee jaar aangepast.

De keuze om 6.8 in Ubuntu 24 te stoppen verbaast me ietwat, ik had daar 6.6 verwacht. Aan de andere kant is e supportbelofte van upstream daarop ook weer niet zo heel lang, zoveel verschil maakt het denk ik niet.

Vergeet echter niet dat deze LTS-versies vaak juist hun patches krijgen of baseren op de patches van partijen als Red Hat/IBM, Oracle, of Canonical. Het is niet dat Canonical gratis de patches zomaar krijgt, ze dragen ook bij aan het porten van patches naar kernels die ze ondersteunen. Het upstreamteam werkt vooral aan de nieuwste versies en backporten waar relevant, maar dat doen ze niet alleen.

[Reactie gewijzigd door GertMenkel op 7 augustus 2024 10:46]

[Speleding]

Tegenwoordig zitten we in de cloud, maar vroeger toen waren iedere keer dat ik een nieuwe server kocht er wel 1 of 2 componenten (RAID, netwerkkaart, etc) die problemen gaven als ik niet de laatste Ubuntu er op zette. Met oudere / andere distributies moet je dan zelf die patches erbij gaan lopen zoeken, wat je niet wilt op productie servers. Dus er is zeker wel behoefte aan een distributie die dicht bij de bleeding edge zit voor bedrijven die af en toe wat nieuws kopen.

[DutchCommando]

5.19 en 6.2 zijn door de auteurs getest. De expliciete vermelding van die twee versies zegt niks over de afwezigheid van de kwetsbaarheid in andere versies. De kwetsbaarheid kan dus ook in andere versies voorkomen.

[Reactie gewijzigd door DutchCommando op 6 augustus 2024 08:41]

[JustFogMaxi]

Kleine moeite om met de laatste versie te testen...

[GertMenkel]

In dat geval: de stappen, vereisten, en scripts staan in het paper en op Github. Kwestie van een apt install in de referentie-VM om een nieuwere kernel te testen. Mensen die willen weten of hun kernels ook getroffen zijn, kunnen dit dus eenvoudig zelf testen.

[RobertMe]

Blijkbaar is dat test image/VM gebaseerd op Ubuntu 22.04 waarin dan die 6.2 kernel zit. Sure, "kleine moeite" om dan ook Ubuntu 24.04 te testen I guess? Maar toch, dat is een mogelijke verklaring daarvoor.

Maar dan nog is het testen met "een Ubuntu kernel" niet heel betrouwbaar, vooral niet bij een oude Ubuntu kernel. Omdat zij nooit version updates doen binnen een release. Ze doen alleen allemaal patches toepassen van fixes op "hun" kernel. Theoretisch kan een issue dus ook ontstaan zijn door een combinatie van patches die incompatible met elkaar zijn of niet goed zijn toegepast of uberhaupt niet goed gebackport door Canonical / de Ubuntu devs. Terwijl het dus best kan zijn dat dan wel allemaal goed is gegaan upstream. Immers zal een patch die wordt ingediend voor bv 6.11 niet per definitie direct toepasbaar zijn op 6.2 (laat staan 5.19 die nog ouder is).

[bwerg]

Blijkbaar is dat test image/VM gebaseerd op Ubuntu 22.04 waarin dan die 6.2 kernel zit. Sure, "kleine moeite" om dan ook Ubuntu 24.04 te testen I guess? Maar toch, dat is een mogelijke verklaring daarvoor.

Hou er ook rekening mee dat dit een wetenschappelijk paper is, en het publicatieproces (inclusief reviewen) duurt een tijd.

[r4ve]

Als zo ik even de paper bekijk is het bedoeld voor een symposium, uitgevoerd door een onderzoeksafdeling geleid door een full professor. Ondanks dat dit geen peer-reviewed paper is, zit er heel wat meer werk in dan aan wat "klasgenoten" vragen om het te beoordelen.

[bwerg]

Nou, nee, het ingediend bij usenix ergens tussen half 2023 en begin 2024.

[Diep]

Niet alleen is het een Proof of Concept onderzoek maar om een technisch antwoord te geven moet je door de paper heen.

We assume that an unprivileged user has code execution. Additionally, we consider the presence of a heap vulnerability in the Linux kernel. We assume that the Linux kernel incorporates all defense mechanisms available in version 6.4, the most recent Linux kernel version when we started our work.

Dit is dus anders dan een CVE. Dit onderzoek laat zien hoe een combinatie van kwetsbaarheden toegepast kan worden gebruik makend van 9 bestaande CVE's. Men gaat niet echt in op patches en andere beveiligingstechnieken. Volgens mij zijn veel CVE's al gefixed maar ik heb het niet in detail onderzocht. De paper gaat meer over complexe exploit mechanisms. Niet over een nieuwe bug ergens.

[fenrirs]

Je wilt niet weten hoeveel VMs er draaien die nog op oude kernels zitten en niet gepatched worden om verschillende redenen.

Het is mij ook niet duidelijk of hosters er expliciet op screenen. Ik heb in ieder geval nooit een berichtje gezien van DO,OVH, Linode of Hetzner.

[vgroenewold]

Om een voorbeeld te noemen; mijn Synology NAS (ja al zeker 10 jaar oud denk ik, maar toch met de nieuwste GUI) blijft hangen op een oude kernel, volgens mij doen ze dat bij alle modellen. Ik heb geen idee of ze dan wel dit soort zaken kunnen patchen.

[Guru Evi]

Aan de ene kant, het is 10 jaar oud, aan de andere kant, hangt het aan het Internet? Je moet al kunnen inloggen of een shell verkrijgen om deze kwetsbaarheid uit te buiten.

Daarnaast doen de meeste Linux (LTS) systemen aan backporting, dus de kernel versie blijft gelijk maar je krijg een 5.4.3-43 voor de "43ste backport patch" (Red Hat en Ubuntu doet dit wat dus ook doorsijpelt naar anderen die onderliggend Ubuntu/Red Hat kernels gebruiken). Red Hat doet dit zelfs voor pakketten zoals Apache etc dus de API blijft steken op 2.4.x maar kwetsbaarheden zijn niet aanwezig. Ik denk dat je meer en meer systemen gaat zien met LTS versies omdat je niet elke 5 minuten kan patchen en mogelijk je applicaties breken omdat je van vb Tomcat 6 naar Tomcat 9 moet voor "de laatste patches".

Isolatie van oudere systemen is meer en meer nodig, alsook 'slimme' firewalls (aka proxies) die kunnen uitvissen welk verkeer/aanvragen een server mag/kan verwerken.

[Reactie gewijzigd door Guru Evi op 6 augustus 2024 17:54]

[aikebah]

Als je van Tomcat 6 naar 9 moet heb je al veel te lang niet gepatcht en heb je last van 'outdated components' en bevind je je al in het gezelschap van de bedrijven met veel voorkomende bekende veiligheidsfouten.

https://owasp.org/Top10/A..._and_Outdated_Components/

[Guru Evi]

Veel mensen draaien Tomcat tot EOL.

Voor Tomcat 6 was het einde van "security support" 31 Maart 2021 en dan moet je naar een 'nieuwere' Tomcat wat rond die periode Tomcat 9 "stabiel" was. Veel applicaties springen dus van 6 naar 9 en gaan wachten tot de EOL van 9 aangekondigd wordt alvorens over te stappen naar wat het dan is (12?)

[aikebah]

Ja, en daarom (veel bedrijven wachten op de EOL om dan pas upgrade actie te ondernemen, of zelfs dan het nog een tijdje nalaten) is het dus ook in die top-10 erbij gekomen

[Reactie gewijzigd door aikebah op 6 augustus 2024 19:49]

[Guru Evi]

Maar het probleem zit niet in Tomcat zelf, Tomcat krijgt updates eerder de developers van verschillende componenten die geen/weinig werk willen steken in een "verouderd" systeem omdat het 1 of 2 versies achterloopt (alhoewel dit vaak de LTS versies zijn). Net zoals de Log4J een volledig vernieuwd Log4J 2.0 maakt maar geen enkele compatibiliteit met Log4J 1 of oudere versies van Java, het had een hack nodig om iemand aan te sporen dit alsnog te doen.

[kodak]

Het is bij apparatuur van een fabrikant meer de vraag of de fabrikant het wil patchen. Daarom zijn heldere afspraken over ondersteuning en eol/eos zo belangrijk. Maar ook dat je als klant beseft dat je zowel bij ondersteuning als bij eol/eos niet zomaar nog veilige apparatuur voor jezelf en je omgeving hebt.

[Reactie gewijzigd door kodak op 6 augustus 2024 12:58]

[aikebah]

Hoewel er genoeg developers zijn die ook liever blijven bij 'oud en vertrouwd' is het toch vaker het management dat er geen capaciteit/onkosten voor vrij wil maken om de software technisch te onderhouden (noch om, waar dat kan zonder breken van bestaande software, de middleware laag waarop gedraaid wordt (zoals bijv. Tomcat) te verhogen als de volgende LTS beschikbaar komt, zodat developers vanaf dat moment nieuwere features ook kunnen gebruiken). Het vereist te vaak brutale ontwikkelaars die 'een library upgrade maar gewoon meenemen in software onderhoud' om nog maar enigszins bij te blijven.

Eén van de tell-tale signs van dit 'geen technisch onderhoud': de verlengde support-periode door Oracle op de Java LTS versie (11) die als de overgangsrelease net nog weinig frictie gezien kan worden tussen Java 8 en Java 8+. Die geeft duidelijk aan dat er in de enterprise wereld nog veel te veel niet van Java 8 naar hogere versies is gebracht.

[blorf]

Het zijn gewoon de hoogste kernel-versies waarvan bekend is dat bepaalde kwetsbaarheden zeer kort na de release zijn gevonden en daar dus nog geen fix in zit.
Wat ik hier mis iis een beschrijving van de benodigdheden. Het lijkt erop dat je sowieso full-TCP/IP LAN toegang, of fysieke toegang nodig hebt. Dan blijven er in de praktijk amper targets over. Het is niet zo dat een kernel al risico's opwerpt door alleen maar opgestart te zijn.

[PGTART]

Bedenk dat veel IoT pc geen onderhoud krijgen en jaren lang iets simpels doen denk aan simpele web displays etc
Dus ook al is het meer ondersteund het.zal nog veel voorkomen al dan niet verbonden aan het internet.

[The Zep Man]

Bedenk dat veel IoT pc geen onderhoud krijgen en jaren lang iets simpels doen denk aan simpele web displays etc

Bedenk dat veel van die PC's geen lokale gebruikers hebben die eigen code uitvoeren.

[anboni]

Maar het is ook weer niet ondenkbaar dat er met behulp van een andere kwetsbaarheid wel eigen code kan worden uitgevoerd waardoor met deze kwetsbaarheid weer meer mogelijk wordt.Da's het verneukeratieve met dit soort kwetsbaarheden, in isolatie bekeken valt het vaak wel mee, maar een goed doordachte aanval stapelt kwetsbaarheden.

[cotix]

Dit soort local privelege escalations worden ook regelmatig gevonden, helemaal als je daadwerkelijk een hoop software op je machine draait. Als een aanvaller user op je machine heeft is het erg vaak al gewoon over. Speciale users die helemaal afgeschermd zijn en alleen een applicatie mogen gebruiken voegt het wel wat toe, maar de meeste mensen draaien alles onder dezelfde user met behoorlijk veel rechten.

[kodak]

Je laat weg dat er bij dit soort grote kwetsbaarheden er net zo regelmatig patches uitgebracht worden. Ook laat je weg dat die patches niet zomaar te laat toegepast worden. Dus het is juist niet zomaar helemaal over, een crimineel heeft immers niet zomaar meer gelegenheid er gebruik van te maken dan dat er gelegenheid is om de crimeel tegen te houden.

Ook de hoeveelheid software wijzigt dat niet zomaar. Die software moet namelijk maar net gelegenheid geven terwijl het dan ondertussen ook nog precies moet samen vallen met gelegenheid de kernel nog fout te kunnen gebruiken. Terwijl die gelegenheid er bij goed beheer juist net zo goed niet zomaar is (of blijft) en zeker niet zomaar icm het niet gepatched hebben van een nog ernstiger probleem in de kernel.

[Reactie gewijzigd door kodak op 6 augustus 2024 13:19]

[cotix]

Ja dat klopt wel, het is een goede extra laag. Maar lang niet genoeg om enkel op te vertrouwen; de eerste stap, de RCE is vaak veel lastiger. Als een hacker eenmaal user heeft ben je al vrij diep in de problemen.

Het is een beetje als een helm dragen op de motor. Zodra je crashed ben je gewoon flink in de problemen, en die helm gaat dat echt niet magisch oplossen. Het vergroot je kansen wel substantieel dat het de moeite waard is om hem te gebruiken

[Reactie gewijzigd door cotix op 6 augustus 2024 13:45]

[Lucb1e]

dat die patches niet zomaar te laat toegepast worden.

Vertel dat aan onze klanten :(

[kodak]

Als je last van klanten hebt terwijl je ze wel als klant wenst te accepteren dan lijkt het me dat je dat dus vooral zelf hoort te regelen in onderlinge voorwaarden over beheer, controles en duidelijke gevolgen voor de verantwoordelijken bij schending.

[Lucb1e]

Ah, sorry ik was niet duidelijk: ik die security consulting dus onze klanten komen juist naar ons toe om kwetsbaarheden in kaart te brengen. Wel graag tienduizend euro over de balk gooien naar consultants, maar apt upgrade draaien is te lastig Ik chargeer de situatie natuurlijk een beetje, maar in sommige gevallen komt het daar wel op neer

[kodak]

Dat advies verkopen lijkt me geen geen beroep waarbij je verplicht maar moet helpen omdat de klant aan eisen moet voldoen en geld geeft. Als je werkelijk ontevreden bent hoe klanten met advies om gaan dan kun je dus prima eisen stellen zodat ze het niet makkelijk blijven negeren. De kwaliteit zit immers niet in het betalen maar in hoe serieus ze je advies willen accepteren. Advies dat men zomaar kan negeren is niet zomaar effectief, tenzij je het vooral doet om geld te verdienen en ondertussen graag ontevreden bent dat ze het niet opvolgen.

[jjchriz]

Bedankt voor de aanvulling. Ik ben zelf niet zo technisch en ben hier om te leren. Jammer dat de orginele schrijver zoveel vaktermen gebruikt en kennis aanneemt imo. Fijn om een beetje context te hebben!

Ik weet zelf amper wat een kernel is haha. Hoeft van mij geen the verge te worden waar alles in baby taal wordt uitgelegd maar n beetje context is wel fijn. Dankt voor je reactie over de impact.

[kozue]

Wat ik mis in dit artikel is hoe dit te misbruiken is. Heb je hier al toegang tot een machine voor nodig (om software te kunnen draaien die dit exploit), of is het genoeg om iemand een speciaal bestand te sturen die dit triggert (en dus root toegang kan krijgen door iemand bv een jpeg of pdf te laten openen)?

[darkfader]

De software moet precies kunnen timen en geheugen kunnen alloceren. RCE lijkt me dan niet van toepassing.
Ik weet niet wat de CVE score is, maar zal redelijk hoog liggen.

[Alfa1970]

En het is niet één CVE, het zijn 9 stuks, en het zijn verschillende scores in de range van 6-9 voor wat ik zo snel bekeken heb.
Sommigen zijn dus gemiddeld, sommigen hoog.
De combinatie ervan, killing.

[InjecTioN]

Precies. Dat is wat veel mensen (en daarmee ook beheerders) over het hoofd zien. Een enkele kwetsbaarheid, kan leiden tot een exploit. Meestal biedt een enkele exploit slechts laag of klein risico. Echter kan de combinatie van verschillende exploits een zeer groot risico zijn. Het is dus ontzettend relevant om ook de kleine kwetsbaarheden zo snel als mogelijk te patchen. Voornamelijk wanneer het publieke diensten betreffen.

[WhatsappHack]

De 9 stuks uit de paper bedoel je? Dat zijn zo te zien kwetsbaarheden waarop deze aanvalsmethode getest is. Dat zijn geen CVE's die horen bij SLUBStick zelf, maar CVE's waarop bekeken is of deze aanvalsmethode erop werkt en wat je er dan mee kan bereiken.

[kuurtjes]

CVE scores zijn totaal niet correct als het om daadwerkelijke veiligheid gaat.

[wica]

Zoals ik het lees, moet je als user toegang hebben tot het systeem. Dat is voor een linux machine niet bijzonder. SLUBStick lijkt vooral een onderdeel te kunnen zijn, voor het misbruiken van andere CVE's

Dus als je PDF reader een bug heeft om code uit te voeren, kan je met SLUBStick meer rechten bemachtingen, dan wenselijk is.

Als bijvoorbeeld, apache (of andere remote bereikbare software) je toe laat om remote code uit te voeren, dan zal SLUBStick een risico zijn.

Maar als het correct is dat het vanaf 5.19 kan, zal de impact beperk zijn, daar de meeste LTS systemen (wat je in productie draait, ja toch?) nog onder deze versie nummer zitten.

Maar de komende dagen, zal wel meer naar buiten komen.

[Reactie gewijzigd door wica op 6 augustus 2024 10:28]

[Lucb1e]

Als bijvoorbeeld, apache (of andere remote bereikbare software) je toe laat om remote code uit te voeren

Veel partijen hebben ook "remote code execution as a service", denk aan shared hosting of container-deployment-diensten of wat ze "serverless" noemen. Daar kun je allerlei code draaien op gedeelde systemen. Of denk aan Android waar je verwacht dat elke app geïsoleerd is en een groot deel van de systemen oude kernels draaien

Of deze bug vanuit bijv. PHP of Java bereikbaar is kan ik niet zeggen, ik heb me nu niet in detail ingelezen (moet gewoon updaten en daarna is 't voor mij alleen relevant wanneer ik het bij een klant tegenkom), maar in het algemeen zijn dit soort privilege escalations behoorlijk breed toepasbaar

[Keypunchie]

Tsja, wat het vaak is, is dat dit soort exploits op zichzelf niet eens zo gevaarlijk zijn, maar dat het vooral iets toevoegt aan andere exploits.

Dan krijg je een hele “ketting” aan exploits, waar je samen mee de controle krijgt.

Dit lijkt me er dan wel eentje die vrij aan het einde staat. Je moet voor deze (voor zover ik het begrijp) al code hebben draaien op de doelmachine.

Maar maakt niet uit met welke privileges, als ik het goed heb. Kan dus ook in user-space.

Het advies voor gewone gebruikers en beheerders blijft: patch early, patch often.

[Reactie gewijzigd door Keypunchie op 6 augustus 2024 08:42]

[Morkatog]

SLUBStick vereist toegang als non privileged user (geen remote execution) en het moet gecombineert worden met een bestaande kwetsbaarheid. Het kan de imapct van een bestaande simpele CVE dus aanzienlijk vergroten, maar staat zover ik begrijp niet op zich.

[WhatsappHack]

Het kan de imapct van een bestaande simpele CVE dus aanzienlijk vergroten, maar staat zover ik begrijp niet op zich.

Het heeft andere kwetsbaarheden nodig om tot uiting te komen, maar het onderliggende probleem in de kernel staat imho natuurlijk wel op zichzelf en daar zou ik dan wel een (of meerdere) CVE('s) verwachten.

[ddofborg]

Zelf checken welke kernel versie je hebt draaien kan via bijv:

uname -r

[Reactie gewijzigd door ddofborg op 6 augustus 2024 14:52]

[WhatsappHack]

Zonder een sluitende lijst van kwetsbare kernelversies kom je daar alleen niet veel verder mee. De twee genoemd in het artikel zijn specifiek getest, maar dat zegt niets over andere versies.

[jan_111]

Is dit probleem gemeld bij de kernel ontwikkelaars en hebben die de kans gehad deze te patchen voor publicatie?

[berchtold]

Altijd weer dat memory gezeik van c en c++…

[im_ik]

Nee, het is een ontlasting berg die sinds de i4004 CPU groot en grooter wordt, bijvoorbeeld;
NUMA is ontwerp fout, cache is ontwerp fout, DMA is ontwerp fout.
Ring0 (kernel mode) in CPU is ontwerp fout.
Gedeeld geheugen en CAS(compare and swap) is ontwerp fout.

Laatste computer welke bijna OK was, is de Tandem T16 (de Terminator computer a 1976)
Correct ontwerp is het omdraaien van het probleem a -1, zo zou ring0 of kernel mode door
het netwerk (zoals pci bus) bepaalt worden en niet op/in een locale processor.

[aileron]

Dit wordt mogelijk gemaakt door een techniek die het precieze moment van geheugentoewijzing identificeert, waardoor aanvallers het hergebruik van geheugen kunnen anticiperen en manipuleren.

Ik ben geen developer, maar het lijkt mij dat dit mogelijk is omdat de kernel open source is.

Dat kunnen sommige misschien opvatten als een nadeel van open source. Maar ik denk dat het aan het licht komen van dit soort zaken linux op langer termijn alleen maar boven de rest doet uitstijgen.

[Lucb1e]

Bij gesloten software kun je dit soort dingen ook vinden. Aan de ene kant is het moeilijker doordat je naar compiled code zit te kijken; aan de andere kant is het makkelijker omdat minder mensen de kans hebben gehad de code goed te bekijken / minder mensen zin hebben gehad zich deze moeite te nemen. In de meeste systemen is wel wat te vinden, met name wanneer ze groot genoeg zijn en in een memory-unsafe programmeertaal geschreven zijn

Iig dat is mijn ervaring als security consultant, maar dit soort kernel of C dingen is niet mijn expertise. Ik krijg dus wel veel mee, maar vind zelf andere typen kwetsbaarheden