Door Jasper Bakker

Nieuwsredacteur

Gaten in het hart van Linux: vijf vragen over snel opeenvolgende kernelbugs

21-05-2026 • 14:00

39

Vijf vragen over snel opeenvolgende kernelgaten in Linux

Een bekende reactie op veel gevallen van beveiligingsgaten in Windows is Linux installeren. Maar nu treft een reeks ernstige kwetsbaarheden dat opensourcealternatief. Het gaat om gaten in de kern van het besturingssysteem, waarmee aanvallers rootrechten krijgen.

Zulk misbruik is niet zomaar op afstand te plegen, in tegenstelling tot bij kritieke gaten zoals Windows die al jaren kent. Toch is het nu alarmfase rood voor Linux, mede door de effectief gebleken inzet van AI-tools om deze kwetsbaarheden te vinden. We bespreken vijf vragen over deze kernelkwetsbaarheden in Linux.

Wat is er aan de hand?

De meimaand heeft dit jaar voor sommige tweakers mogelijk een nieuwe reputatie. Naast een oud spreekwoord over vogels, een Nederlandse tv-zenderslogan, een Tilburgse traditie en biodiversiteitsadvies krijgt deze maand nu een cybersecuritysausje.

Mei 2026 zag niet één, niet twee, niet drie, maar tot nu toe vier ernstige kwetsbaarheden in de kernel van Linux. Beveiligingsonderzoekers ontdekten gaten in die diepste kern van het besturingssysteem, waarna snel patches, maar ook publieke exploitcode volgden.

Security/Hackers/Hack. Bron: Witthaya Prasongsin/Moment/Getty Images
Hacker. Bron: Witthaya Prasongsin/Moment/Getty Images

Op zich zijn kwetsbaarheden in software niet uitzonderlijk. Alle code kan bugs bevatten, die mogelijkheden tot misbruik kunnen bieden. Zelfs de kernel van een besturingssysteem is daar niet van gevrijwaard. Misschien leek het vorig jaar alsof er ineens een stijging was van ontdekte kwetsbaarheden in de Linux-kernel. Dat kwam vooral door een beleidswijziging in het toekennen van nummers in de kwetsbaarhedendatabase CVE (Common Vulnerabilities and Exposures).

Wat nu wél uitzonderlijk is, is hoe snel van deze vier ontdekte kernelkwetsbaarheden met flinke impact elkaar opvolgen. Drie hiervan kregen klinkende namen: Copy Fail, Dirty Frag en Fragnesia. De vierde, nu net onthulde kwetsbaarheid mist nog wat marketing en is vooralsnog alleen bekend onder het toegekende nummer in de CVE-database. Deze CVE-2026-46333 krijgt ook wel de aanduiding 'ssh-keysign-pwn', naar een van de uitgebrachte exploits hiervoor. De teller voor beschikbare exploits voor dit vierde kernelgat staat nu op twee stuks.

De eerdere drie kernelkwetsbaarheden hebben ook hun eigen CVE-nummers: Copy Fail heeft CVE-2026-31431, Dirty Frag heeft CVE-2026-43284 plus CVE-2026-43500 en Fragnesia heeft CVE-2026-46300. Dirty Frag bestaat uit twee bugs die in gecombineerd gebruik de daadwerkelijke kwetsbaarheid opleveren.

Informatiever dan de nummeraanduidingen zijn de cijfers die de ernst van deze beveiligingsgaten aangeven. Copy Fail scoort een 7,8 op de CVSS-schaal van 10, Dirty Frag scoort een 8,8 en een 7,8 voor de twee onderliggende kwetsbaarheden, Fragnesia scoort een 7,8 en de vierde Linux-kernelkwetsbaarheid scoort ook een 7,8.

Hoe eenvoudig zijn deze kernelkwetsbaarheden te misbruiken?

De genoemde securityscores vallen op het eerste gezicht mee. Windows kreeg in Microsofts patchronde van deze maand nog updates voor kritieke kwetsbaarheden met CVSS-scores van 9,1 en zelfs 9,8. De relatief lage score van de Linux-kernelkwetsbaarheden is te danken aan mitigerende factoren. Zo is er een lokaal account nodig om er misbruik van te maken. Een ingelogde gebruiker kan op Linux-systemen de toegekende rechten drastisch verhogen: tot het verregaande niveau van root.

De kans op misbruik is hierdoor minder groot. Daarentegen is de impact van misbruik wél heel groot. Dit kan kwaadwillenden motiveren om andere bugs te verkennen, waarmee die vereiste van een lokaal account een eerste horde wordt. Verschillende kwetsbaarheden 'aaneenrijgen' om dan systemen te kunnen hacken, doen aanvallers wel vaker. Dirty Frag is hiervan een actueel praktijkvoorbeeld.

Het is natuurlijk makkelijker gezegd dan gedaan om nog een derde, vierde of vijfde bug te combineren om tot een geslaagde aanval te komen. De 'beloning' voor zulk werk is juist groot, dus kan dit zeker de moeite waard zijn.

Ubuntu 26.04 LTS Resolute Raccoon
Ubuntu 26.04 LTS Resolute Raccoon

Bijkomend probleem is dat misbruik in sommige gevallen wel erg makkelijk te plegen is, als de horde van lokale toegang eenmaal is genomen. In het geval van Copy Fail hoeft een aanvaller met een lokaal account alleen een klein Python-script te draaien. De ontdekkers van deze kernelkwetsbaarheid melden dat het benodigde script slechts 732 bytes groot is.

In het geval van Dirty Frag volstaat een enkel commando om rootrechten te krijgen op een ongepatchte Linux-installatie. Root is machtiger dan een beheerdersaccount en geeft onbegrensde mogelijkheden voor alle bestanden, instellingen en software op het hele systeem.

Treffen deze kwetsbaarheden alle Linux-distro's?

Ja: Tails, Ubuntu, Debian, Red Hat, Fedora, SUSE en vele andere distributies zijn vatbaar. Maar daarnaast raken deze gaten ook Linux-uitvoeringen die intern bij cloudaanbieders draaien, zoals AWS Linux van Amazon en Azure Linux van Microsoft.

Microsoft loves Linux, ceo Satya Nadella. Bron: Microsoft
Microsoft loves Linux, ceo Satya Nadella. Bron: Microsoft

Dat laatste maakt het gevaar wat groter. Op zulke systemen zijn er vele gebruikers die legitieme accounts hebben. Zulke bestaande accounts zijn in de regel beperkt tot lokale rechten, maar zijn door deze kwetsbaarheden te verheffen tot root. Waakzaamheid is dus belangrijker dan ooit: goede monitoring, strikte isolatie, op de hoogte blijven, mitigerende maatregelen nemen en andere logische beveiligingsstappen zetten, naast natuurlijk patchen.

Er zijn toch patches, dus geen probleem meer?

Er zijn inderdaad patches beschikbaar. De tot nog toe gevonden kernelkwetsbaarheden zijn verantwoord gemeld. Daardoor konden de kernelontwikkelaars van Linux de bugs onderzoeken en patches maken. Die patches verschenen snel en de diverse Linux-aanbieders brachten ze vlot uit voor hun respectievelijke distributies.

Gewone gebruikers krijgen deze patches aangeboden en kunnen die installeren. Daarbij is de snelheid van dit updaten minder kritiek. Consumenten lopen wat minder risico vanwege de vereiste van lokale rechten voor misbruik van de kernelkwetsbaarheden.

Bij organisaties die Linux gebruiken ligt dit wat anders: daar is snelheid belangrijker. Waakzame beheerders maken niet alleen haast met het installeren van de patches. Ze nemen ook mitigerende maatregelen – als die beschikbaar zijn – om kwetsbare functionaliteit af te schermen. Door zulk kordaat handelen zijn beveiligingsgaten niet meteen een groot probleem.

Daarvoor is het wel nodig om het updatewerk snel uit te voeren. Dit geldt zowel voor de ontwikkeling van die updates als voor de installatie ervan door Linux-gebruikende organisaties.

Een niet onbelangrijk detail is dat de vierde kernelkwetsbaarheid van mei neerkomt op een vierde reboot van Linux-systemen in krap drie weken tijd. In ideale opstellingen is er redundantie door gebruik van meerdere servers die elkaar opvangen als er een uitvalt of moet herstarten voor een update van de kernel. Een reboot vormt dan geen probleem.

Linux, patch. Bron: PATCHION
Linux-patch. Bron: Patchion

De praktijk heeft niet altijd ideale opstellingen. Updaten gebeurt niet altijd snel en reboots kunnen wel degelijk impact hebben. Dit kan bijvoorbeeld door budgetkeuzes voor systemen of door capaciteitsgebrek bij beheerders. Bij verantwoord systeembeheer hoort ook patches testen, wat menskracht en tijd kost.

Simpelweg de beschikbaarheid van patches staat dan ook niet gelijk aan het gepatcht hebben van software. Weliswaar is dit een groter probleem bij consumenten die Windows gebruiken dan bij gebruikers die bewust voor Linux kiezen. Toch kan er tijd zitten tussen het uitkomen van patches en het gepatcht hebben van kwetsbare systemen.

Is het AIpocalypse nu?

Naast de tijd tussen verschijning van patches en installatie daarvan is er tijd nodig na de ontdekking van kwetsbaarheden om er patches voor te maken. Ook daarop ligt druk en die neemt nu toe door de effectieve inzet van AI-securitytools om code te scannen op kwetsbaarheden.

Betekenen de snel opeenvolgende ontdekkingen van Linux-kernelkwetsbaarheden dat de gevreesde AIpocalypse nu is aangebroken? Het lijkt erop dat de door AI-experts en beveiligingsonderzoekers voorspelde golf aan beveiligingsproblemen aanzwelt. Dit gaat dus niet om beveiligingsproblemen die ontstaan door AI-geschreven code, maar om beveiligingsproblemen die door AI zijn gevonden in bestaande code.

Mythos. Bron: Anthropic
Mythos. Bron: Anthropic

Zo ontdekte Firefox-maker Mozilla onlangs dankzij AI 271 bugs in zijn browsercode. De in april uitgekomen versie 150 van de opensourcebrowser repareerde dat indrukwekkende aantal bugs, die Mythos van Anthropic had gevonden. Daarentegen vond diezelfde AI-securitytool in de veelgebruikte commandlinetool curl slechts vijf kwetsbaarheden, waarvan er vier onterecht bleken. Ondertussen biedt Anthropic-concurrent OpenAI een eigen AI-securitytool.

De verschillen in omvang van de code van curl, Firefox en Linux zijn wel significant. Hoe groter de codebasis van een stuk software is, hoe groter de kans op bugs. Door de aard van opensource kan iedereen naar de broncode kijken en dus bugs vinden, melden en fixen. Dit heet de Wet van Linus, vernoemd naar Linux-maker Linus Torvalds, die ooit stelde: "Vele ogen maken alle bugs ondiep."

Linus Torvalds GitHub
Linus Torvalds' GitHub

Voor dit voordeel van opensource is het wel nodig dat er genoeg mensen met voldoende expertise kijken naar de code. Tot nu toe zijn er zulke experts en werken zij mee aan de verbetering van software. Daartegenover staan andere experts die doelbewust zoeken naar bugs om die uit te buiten. Dit geeft een ratrace, waarbij soms de kwaadwillenden even een voorsprong claimen.

De omarming van AI-tools verandert deze dynamiek. Weliswaar zijn AI-modellen en -toepassingen zeker niet onfeilbaar en 'verzinnen' ze ook zaken. In het geval van bugs en bugmeldingen kan dit een overdaad aan AI-slop geven. Voor gemotiveerde beveiligingsonderzoekers en aanvallers valt er in die stortvloed wel goud te vinden. Dat merkten ook de ontdekkers van deze kernelkwetsbaarheden, toen ze AI-tools de opdracht gaven om verder te speuren naar soortgelijke bugs. De ene kernelkwetsbaarheid leidde als het ware naar de andere.

Eind april waarschuwde beveiligingsexpert Josh Bressers al dat de Wet van Linus toe is aan een realiteitscheck. Gebruik van AI-tools op basis van grote taalmodellen (llm's) brengt schrikbarend veel bugs aan het licht, schreef hij voordat de kernelkwetsbaarheden bekend werden.

Het maakt volgens Bressers niet uit of een opensourceproject groot of klein is. Ook de kwaliteit van een AI-tool doet er niet heel veel toe. "Zelfs de slechte llm's vinden dingen." Een broodnodige herziening van de Wet van Linus is volgens hem dan ook dat 'vele llm's ervoor zorgen dat je kwetsbaarheden voor eeuwig blijft onthullen'.

Redactie: Jasper Bakker • Eindredactie: Marger Verschuur

Reacties (39)

Sorteer op:

Weergave:

Dat is dan wel weer mooi dat men met AI de bugs kan opsporen om deze vervolgens te kunnen patchen zo krijgen we dankzij AI een veiligere wereld en kunnen achterdeurtjes ook makkelijker ontdekt worden.
Dat is een misvatting, je kunt frontier modellen die nog niet publiek toegankelijk zijn de opdracht geven om kwetsbaarheden op te sporen of achterdeurtjes te implementeren die huidige modellen nog over het hoofd zien. Dat zal wel een tijdje zo blijven.

En closed source maar 'open' binaries is niet veel veiliger hoor, dmv Ghidra kunnen binaries gedecompileerd worden, door AI geannoteerd worden wat welk stuk code doet en kwetsbaarheden worden opgezocht.

Hacks van hacker groepen zullen hiertoe bijdragen dat deze binaries beschikbaar komen als deze er nog niet zijn. Ik denk niet dat er iets veilig is, tenzij je een airgapped systeem hebt, of een systeem dat maar weinig aan gezet wordt.

Je kunt dan wellicht gaan spreken van een cloudpocalypse, waarbij cloud diensten op grote schaal worden aangevallen en uitgebuit, afhankelijk hoeveel geld er uit te halen valt. En afhankelijk of kwaadwillende partijen kunnen beschikken over dergelijke nog niet publiek toegankelijke modellen. Mijn verwachting is dat dat al gebeurd.
Dankzij die ransomware groepen krijgen we ook een veiligere wereld. ;-)
AI is inmiddels zover dat het vulnerabilities kan vinden. Een oud-collega van mij (een dev) sprak de wijze woorden "software is kapot, hardware gaat kapot". Nu zou je denken dat de Linux kernel en Firefox ontzettend kwetsbaar zijn want er wordt veel gevonden. Dat is echter een vertekend beeld. Open Source software is door iedereen te auditen, dus ook AI. Mozilla heeft toegang tot Mythos en is zo eerlijk toe te geven wat de resultaten zijn en de problemen te patchen.

Closed source makers als Microsoft zullen ook met Mythos werken maar maken waarschijnlijk niet bekend wat daaruit komt.

Ik denk dat iedere softwaremaker voor gaas gaat als je iets als Mythos erop loslaat.
Open Source software is door iedereen te auditen, dus ook AI.
Klopt, en niets en nadele van Open Source maar dat iedereen het kan auditen betekende dus tot de komst van AI niet dat het ook gebeurde. Én het geeft de complexiteit aan van software en de onderlinge afhankelijkheden daarin. Hetzelfde geldt overigens ook voor closed software hoor. Maar er zijn mensen die beweren open source is veiliger want iedereen kan het controleren zonder enig voorbehoud. Dat is de theorie maar zelfs in de Linux kernel is dat niet geen zekerheid.
Het controleren van code werd wel degelijk gedaan, maar je kunt als normale sterveling niet de hele codebase door om dergelijke bugs te vinden.

Deze copyfail en soortgelijke bugs zaten in een stukje zero copy code die nu in zijn geheel wordt verwijderd en vervangen door code die alsnog een kopie maakt: https://www.phoronix.com/...AF-ALF-Zero-Copy-Security

Na de vondst van de eerste bug is het gewoon wachten op de volgende.
Er zijn door de jaren heen voldoende bugs boven water gekomen in FOSS die er ook jarenlang hebben ingezeten simpelweg omdat niemand er naar keek, omdat niemand er naar op zoek ging. En ook dat is niet rampzalig, maar we moeten ook eens ophouden met te denken dat FOSS zaligmakens is omdat het open source is. Ja, het heeft heel wat voordelen, maar die worden niet altijd ten volle benut.
Open source is niet per se veiliger, naast dat je zelf bugs op kunt lossen kan iemand anders er ook actief naar zoeken, al helemaal met AI. Dat is bij closed software net even wat ingewikkelder omdat je de code niet bij de hand hebt.

Ik heb ooit een DoS afgewend op een DNS server met PowerDNS. Zat een escaping bugje in de database backend code die de backend thread liet crashen bij een bepaalde query. Als je die query maar vaak genoeg krijgt doet je DNS server het niet meer. Diagnose en patchen was een uurtje werk.

Kreeg laatst een AI-generated documentje voor wat config die ik moest aanpassen in Dovecot. Uiteraard niet werken. Leg de documentatie ernaast: zou gewoon moeten werken. Pak de code erbij... werkt toch anders...

Maargoed, dan zijn dit nog relatief simpele stukjes software met logging all over the place, als je mij zoiets vraagt over LibreOffice of Samba schiet ik gewoon een ticket in, mag het ontwikkelteam oplossen.
Als aanvulling een verhaal over OS'en en security:

Er was een tijd waarin mac os werd gezien als het onbreekbare OS, volgens de mac liefhebbers waar ik toen werkte in elk geval. Een maand of drie later kwam uit dat je het inlogscherm kon passeren door de spatiebalk vast te houden om een overflow te creeeren... Dit was pre mac os x voor de goede orde, dus closed source. Soortgelijke slechte verhalen zijn er ook over aix, sun os, diverse windows OS'en, zelfs novell netware had iets dat bassaal makkelijk was om te exploiteren. Er zijn ook verhalen over software voor routers en switches.
Ik ken ook iemand die al decennia lang fervent Mac liefhebber is en die ik al vrij snel dingen heb horen beweren over MacOS die niet bleken te kloppen. Toen ik hem daar later een keer op aanspraak zei hij doodleuk: "Oh ja, da's waar ook." :(

Het enige waar we het unaniem over eens waren was de kwaliteit van de hardware van Apple.

Het heeft best lang geduurd voor ik er met mezelf uit kwam wat nu precies mijn meest favoriete OS was. Dat verschoof namelijk nogal eens. De ene periode stond Windows bovenaan, de andere periode MacOS en vandaag de dag is het Linux. Ik werd er af en toe best een beetje zeeziek van ;)

Wat overall security betreft staan Windows en MacOS voor mij op een gedeelde eerste plaats en Linux op de tweede plaats, maar geen haar op mijn hoofd die er over denkt om van Linux af te gaan stappen.

[Reactie gewijzigd door Uruk-Hai op 21 mei 2026 15:50]

Microsoft heeft veel gedaan hieraan de afgelopen jaren, maar het was lange tijd vreselijk. Niet zo heel lang geleden kon je nog met die algemene led driver een windows systeem overnemen. Meen dat dat ding nog gesigned was ook. Was dat opgelost in 2023? Of mss zelfs in 2024.

Ga er maar vanuit dat het allemaal contant bijgewerkt moet worden, dat zal nog wel een tijdje zo blijven. Als je iets meer wilt op het gebied van security dan is er altijd nog openbsd... Die hebben het best goed gedaan altijd (al lopen ze altijd achter met features en ondersteuning helaas).
Klopt, en niets en nadele van Open Source maar dat iedereen het kan auditen betekende dus tot de komst van AI niet dat het ook gebeurde.
Ik denk dat de komst van AI op een andere manier de pendulum laat zwaaien. Vroeger kon iedereen de code van Linux bekijken en bugs melden. De Windows-code was maar voor een beperkt aantal ogen. Hierdoor was het risico op misbruik en de kans op patches bij Linux groter.

Nu (en dan bedoel ik echt, op dit moment, niet vanaf nu) wordt code vooral gereviewd door LLM's. Dat voordeel beperkt zich niet tot Open Source. Waar bij Linux zowel de kans op patches is toegenomen maar de kans op misbruik ook, is bij Windows alleen de kans op het vinden van bugs en het maken van patches toegenomen. Doordat het gebruik van een LLM binnen de deuren van Microsoft kan gebeuren, hebben kwaadwillende niet meer toegang gekregen dan ze al hadden.

Ik hoop dat ik het verkeerd zie, of dat er een oplossing voor dit probleem komt, maar op dit moment ben ik bang dat close source software (sneller) veiliger wordt dan open source software.
Nu (en dan bedoel ik echt, op dit moment, niet vanaf nu) wordt code vooral gereviewd door LLM's.
Dat is nogal een bold statement die je ook niet kan aantonen. Elke change in de Linux kernel word echt nog wel door mensen gereviewed.

Maar nu vraag ik mij af, In de meeste gevallen is de review scope van een MR review tot de expliciete veranderingen in die change, en niet tot het geheel van de code base. Een verandering in de ene module zou een bug in de andere module kunnen maken. Kijken die LLMs wel naar de volledige applicatie scope?

Wat nou als ik 2 onafhankelijke MRs indien die samen een bug introduceren. Als de MRs niet serieel gereviewd worden in de volledige applicatie scope, heb je alsnog een probleem.

De succesverhalen van Mythos, en andere AIs, blijken voornamelijk "guided analyses" te zijn. In C/C++ code is het over het algemeen zoeken naar de unrestricted copy acties, of allocaties en free's, waar de mogelijk issues zijn. (Dingen waar PVS Studio ook enorm op controleert.) Op een LLM los te laten op de volledige applicatie scope naar elke merge lijkt me niet heel schaalbaar.
ik bang dat close source software (sneller) veiliger wordt dan open source software.
Microsoft bewijst dat dit niet het geval is.
Dat is nogal een bold statement die je ook niet kan aantonen.
Dat kan ik niet aan tonen, maar ik kan uitleggen waarom ik het aan neem. Ten eerste ga ik er van uit gaan dat er meerdere LLM's de gehele code van bijvoorbeeld de Linux kernel heeft doorgenomen gedurende de afgelopen maand. Hoeveel mensen denk je dat alle code hebben doorgenomen?

Ten tweede zie je bij veel Open Source projecten dat ze seriues last hebben van bug reports door AI. Dat betekent dat een significant aantal reports door AI wordt gegenereerd, ik ga er voor het gemak van uit dat dat meer dan de helft is.
Kijken die LLMs wel naar de volledige applicatie scope?
Weet ik niet. Ik weet wel dat mensen dat gegarandeerd niet doen, daar is ons geheugen veel te beperkt voor.
Microsoft bewijst dat dit niet het geval is.
Dat is een opluchting. Hoe bewijzen ze dat?
[...]

Maar er zijn mensen die beweren open source is veiliger want iedereen kan het controleren zonder enig voorbehoud. Dat is de theorie maar zelfs in de Linux kernel is dat niet geen zekerheid.
Dan ga je uit van 100% en de aanname dat het vinden van een bug software onveiliger maakt.

Ik denk dat er wel degelijk een (positieve) correlatie tussen OSS en veiligheid is maar dat deze niet aan te tonen is. Als de Wet van Linus van toepassing is op stabiliteit van het systeem dan moet dat gezien de enorme spreiding ook van toepassing zijn op veiligheid.

De continue transparantie heeft daarnaast een vooruitwerkende kracht bij ontwikkeling en het al dan niet beschikbaar zijn van source code kan alleen maar een positief effect hebben omdat ik verwacht dat de meeste professionele hackerorganisaties toch wel de code gejat hebben, veel strenger bewaakte IP is ooit ook gelekt.
Maar als ik een dit artikel lees betwijfel ik of dit ook terechte bevindingen zijn?
Curl is een decennia oude tool die verbazingwekkend veel wordt gebruikt. Daardoor is het in feite jarenlang door de hele wereld getest in allerlei situaties. In al die tijd zijn er vele bugs gevonden en opgelost. Ik vind het nog best knap dat ze met AI een bug in Curl weten te vinden, gezien hoe battle-hardened die code is.
Curl is een decennia oude tool die verbazingwekkend veel wordt gebruikt
De Linux-kernel ook. Waarschijnlijk bedoel je te zeggen dat curl, in tegenstelling tot de Linux-kernel, de afgelopen tien jaar bijzonder weinig grote veranderingen heeft ondergaan, en het grootste deel van de code ook echt oud is?
functionele bugs zullen er niet inzitten, maar security test je niet noodzakelijk met veelvuldig gebruik. De eenvoudig te triggeren exploits haal je er zo wel uit, maar wat AI kan doen, en wat voor mensen enorm moeilijk is, is context uit heel de codebase bij elkaar zoeken om zo exploits te vinden. Al helemaal als je kleine foutjes met elkaar moet verbinden die in zulks een diverse stukken van de code zitten dat deze door meerdere mensen onderhouden worden omdat ze zo complex zijn en wij als mens moeilijk het totaalplaatje kunnen vasthouden daardoor.
Meerdere ontwikkelaars dit geuit. Het probleem is niet zozeer dat AI dit niet kan. Het probleem is dat veel mensen makkelijk geld proberen te verdienen dmv het inzenden van rapporten. Deze rapporten moeten door een mens behandeld worden. Dit kost bergen aan fte's.

Sprak gisteren nog iemand van een software bedrijf. Om het behapbaar te houden hebben ze besloten dat als ze de eerste 10 minuten een AI gevoel krijgen ze stoppen met het rapport en de indiener te vragen hoe ze het kunnen reproduceren en testen. Was volgens hem niet ideaal maar het filtert wel een beetje
en de indiener te vragen hoe ze het kunnen reproduceren en testen.
Dat is bij mijn weten toch normaal om dit in het initiële rapport toe te voegen. Anders wordt het gewoon niet bekeken. Wat is daar niet ideaal aan? :)
ZO staat het wel in de Linux documentatie beschreven dat er wel een exploit moet zijn, die dan eerst geheim gehouden moet worden, maar wel moet worden gedeeld.
Beetje verkeerd beschreven. Ze vragen de indiener om het te laten zien via een screenshare sessie. Niet ideaal omdat ze enorm veel tijd kwijt zijn aan het coördineren. Heeft best wat impact op een relatief klein team
Het kan maar zo dat AI 10-20 "vulnerabilities" in de Linux Kernel heeft gevonden. Nadat de devs daar de stofkam doorheen hebben gehaald hebben ze er uiteindelijk 3-4 over. Die halen het nieuws.

De schrijvers van Curl vinden er ook eentje, maar melden erbij dat AI ook wat slop opleverde. Dat haalde ook het nieuws.

Helpt AI? Zeker! Iedere bevinding zal apart getoetst moeten worden om te valideren. Dat is op zich al minder werk dan de hele code door harken. Neemt niet weg dat AI waarschijnlijk niet alles kan vinden. AI wordt ook beter dus verwacht dat er nog meer gevonden gaan worden.
Closed source makers als Microsoft zullen ook met Mythos werken maar maken waarschijnlijk niet bekend wat daaruit komt.
Zodra fixes door MS gepubliceerd worden wordt ook omschreven wat de fix inhoudt en waar de kwetsbaarheid zit, en wat er als mitigatie mogelijk is zonder patch.

Wat me wel verbaast is dat elk van de hier genoemde patches een reboot nodig heeft; dat is zelfs op Windows tegenwoordig al regelmatig niet meer het geval. (Behalve op Home dan, waar het wél maandelijks noodzakelijk is.)
Voor copy fail en dirty frag hoef je niet te rebooten. Dat is alleen nodig als je die module had geladen of de code in je kernel had zitten in plaats van in een kernel module.
Eens met het eerste stuk, ze zullen alleen niet aangeven hoe ze het gevonden hebben.

Het probleem zit in de kernel. Dat is de reden dat een herstart nodig is
Microsoft maakt dat zeker wel bekend. Waarom denk je dat de April patch tuesday een enorme hoeveelheid vulnerabilities fixed? Microsoft fixes 167 security flaws in April, second biggest Patch Tuesday ever | PCWorld

Wat dat betreft is Apple over het algemeen zuiniger met wat er gefixed wordt. Daar staat over het algemeen bij een update alleen 'security updates'.

Wat dit hele AI op opensource het meest interessante maakt is de hoeveelheid die daar nog gevonden wordt. Bijvoorbeeld bij curl. 1 correct, 4 incorrect. De ene correcte is gigantisch als je bedenkt dat curl niet een hele grote codebase heeft, die al door meerdere AI tools is gebruikt om problemen te vinden en dus al flink is gepatched.

Daar komen deze kernel bugs nog bij, die ook al jaren in de codebase van de kernel zaten zonder dat iemand ze had opgemerkt.

Dat zegt iets over wat de AI tools waarschijnlijk vinden in closed source. Dat zie je zowel bij Firefox (die van maandelijks naar wekelijkse patches gaat) en bij Oracle (die van kwartaal naar maand patches gaat... al vind ik iets van de eerdere kwartaal patches)

Het zou mij niet verbazen als Microsoft ook naar een snellere update cyclus gaat. Van maandelijkse bundel patches met wekelijkse kleinere update packs met minder impact patches. Zeker waar het Windows 11 (de client OSen) betreft.
Grappig dat Curl wordt genoemd, die waren in januari nog in het nieuws omdat ze stopten met hun bug-bounty programma omdat er zo veel AI-slop bug-reports werden gedaan.

Zie https://www.bleepingcomputer.com/news/security/curl-ending-bug-bounty-program-after-flood-of-ai-slop-reports/
De ene AI is de andere AI niet.

Als iemand letterlijk de broncode van een stuk software in ChatGPT stopt met de prompt "Zoek de fouten om me rijk te maken", dan is dat natuurlijk heel wat anders dan een AI-model dat is gespecialiseerd in C lezen, die de code interpreteert en actief probeert 'te hacken' (bij gebrek aan een betere term :))

En niks ten nadele van ChatGPT hè? Want die is bijvoorbeeld weer best goed in Sinterklaasgedichtjes maken ;)
ChatGPT Codex werk anders best aardig.
De ene AI is de andere AI niet.
En het ene softwareproject is het andere niet. cURL en SQLite worden vaak als de husarenstukjes onder de software gezien. Deze twee softwareprojecten zijn relatief klein, met een kleine groep hooggespecialiseerde ontwikkelaars. Dit in tegenstelling tot enorme projecten zoals de Linux kernel of Firefox, waar enorm veel verschillende ontwikkelaars aan werken, met ook heel wisselende achtergronden en kwaliteit.

Ik denk dat dit ook meespeelt waarom bijvoorbeeld de ontwikkelaar van Curl zegt dat Mythos tot op heden vooral marketing is terwijl een project zoals Mozilla enorm veel voordeel uit Mythos lijkt te halen en om deze reden bang is voor een tweedeling in de softwarewereld.
Het probleem was dat de meeste services, zoals Apache, ook als lokale gebruiker draaien, waardoor een exploit via een webserver gelijk tot root rechten kon gaan als deze exploits via de andere exploit konden worden uitgevoerd.
En hoeveel bugs heeft de Windows NT kernel die niet "openbaar" is als Linux? My guess, niemand weet echt maar het zal meer zijn!
Mooi artikel, helemaal in de lijn wat de gevoelens/gedachten bij veel sysadmins (en developers) zijn de laatste tijd als ik om me heen kijk.

Moet open-source maar weer closed-source worden? Security through obscurity? ;)

Of kunnen we er eigenlijk vanuit gaan dat ook dit proces (uiteindelijk) weer verbetering te weeg gaat brengen in de code?

Sterkte voor alle mensen die de aangedragen bugs moeten controleren op juistheid en een fix moeten implementeren en, niet te vergeten, namens een heleboel mensen en organisaties : bedankt! :D
"Zo ontdekte Firefox-maker Mozilla onlangs dankzij AI 271 bugs in zijn browsercode. De in april uitgekomen versie 150 van de opensourcebrowser repareerde dat indrukwekkende aantal bugs, die Mythos van Anthropic had gevonden. Daarentegen vond diezelfde AI-securitytool in de veelgebruikte commandlinetool curl slechts vijf kwetsbaarheden, waarvan er vier onterecht bleken. Ondertussen biedt Anthropic-concurrent OpenAI een eigen AI-securitytool."

Beetje vreemd om het aantal bugs die gevonden wordt in curl te vergelijken met een browser, die vergelijking slaat nergens op en daar kan je geen enkele conclusie uit trekken. Mozilla browser heeft om te beginnen al minstens 100x meer lijnen code dan curl.
Ik zou vooral geïnteresseerd zijn in een AI security analyse van bekende compilers. #verstrekkendegevolgen
Het opensource karakter van Linux is zowel een sterkte als een zwakte. Doordat Linux opensource is, krijg je heel veel verschillende smaken en varianten. Elke smaak moet gepatched worden om dit probleem tegen te gaan. Heeft de ontwikkelaar hier geen tijd/zin in, dan blijft jouw OS versie kwetsbaar.
Stel dat een hoop routers/switches/andere IOT devices zijn geleverd met een Linux variant die nu kwetsbaar blijkt te zijn, dan is het maar hopen dat elke fabrikant dit gaat fixen. Anders heb je een probleem.

Dit in tegenstelling tot iets als Windows, wat gewoon 1 OS is met 1 bedrijf als ontwikkelaar. Bug gevonden? Patchen en klaar. Paar Windows versies te onderhouden, en that's it.

Om te kunnen reageren moet je ingelogd zijn