Linux-kernel blijkt kwetsbaar voor usb-aanval

Een Chrome OS-ontwikkelaar heeft twaalf lekken in de Linux-kernel gevonden. Via een van de lekken is met een usb-apparaat geheugencorruptie te veroorzaken, wat het uitvoeren van kwaadaardige code mogelijk maakt. Beveiligingsonderzoeker Cook heeft een patch klaarstaan.

Kees Cook, een ontwikkelaar van Google Chrome OS, heeft twaalf kwetsbaarheden gevonden in hoe Linux omgaat met hid's. Hij deed deze ontdekking door met usb-apparaten te experimenteren. Het ergste lek dat Cook ontdekt heeft, kan geheugencorruptie veroorzaken en stelt een aanvaller in staat om kwaadaardige code uit te voeren.

Zodra een gebruiker een hid-device via usb op het systeem aansluit, stuurt het apparaat berichten naar de kernel van het besturingssysteem. De kernel beperkt het aantal datavelden dat in deze gebeurtenissen voor mag komen tot 256. Een apparaat dat een report id met meer dan 255 entries stuurt, veroorzaakt een segmentation fault in Linux.

Cook ontdekte de fouten terwijl hij bezig was met een eigen project, zijn Facedancer-board. Dit testbordje, dat aangestuurd wordt door een Python-script, stuurt in realtime usb-commando's naar een systeem. Hiermee kan het board data wegschrijven naar het geheugen van het systeem waarop het is aangesloten, mits dat systeem Linux draait. De aanval is ook mogelijk met een Teensy-board die dezelfde functies heeft als Cooks Facedance-board, maar slechts de grootte heeft van een usb-stick.

Volgens Cook zijn Debian Wheezy en Red Hat, zowel Fedora 19 als Enterprise Linux 6, vatbaar voor het lek. De Fedora- en Debian-ontwikkelaars werken aan een patch. Canonical is nog aan het onderzoeken of Ubuntu vatbaar is. Overigens heeft Cook al zijn eigen patch uitgebracht.

Reacties (52)

[wildarch]

Op zich lijkt het allemaal wel mee te vallen met die kwetsbaarheden:
1. De ergste (en enig goed te exploiteren) kwetsbaarheid werkt alleen op 32-bit systemen
2. Diezelfde kwetsbaarheid kan enkel worden gebruikt om een zelfgeschreven 'Kernel pointer' weg te schrijven in het geheugen. Dit is iets totaal anders dan bijvoorbeeld een script of binary. Overigens kan die 'Kernel pointer' wel gebruikt worden om een binary uit te voeren, al is het hiervoor noodzakelijk dat een eventuele hacker zich erg uitgebreid in de materie verdiept voordat hij dit voor elkaar krijgt.

Al met al zal het waarschijnlijk wel enige tijd duren voordat iemand in staat is deze kwetsbaarheid daadwerkelijk te misbruiken is, waarschijnlijk zijn er dan al wel patches voor uitgebracht. Voordat jan met de pet er een metasploit module voor kan vinden, heeft elke verstandige systeembeheerder zijn kernels op orde, maar dat is natuurlijk slechts een schatting. De tijd zal het leren..

[thegve]

Deze bug is alleen nuttig als je fysieke toegang hebt tot het systeem, vooral desktops dus. Elk nadeel heb zijn voordeel, het marktaandeel van Linux op de desktop is redelijk beperkt. Het grootste gevaar zijn industriële systemen denk ik.
In datacentra heb je meestal wel afdoende fysieke beveiliging.

[ATS]

Of als je wat USB sticks rondstrooid natuurlijk. Je zou niet de eerste zijn die het probeert.

[Junketsu]

Ik heb even wat rondgelezen, maar kan een zogenaamde 'segmentation fault' altijd gebruikt worden om malafide code te injecteren? Mijn ervaring is dat bij voorgenoemde fout, het proces wordt afgesloten.

[.Peter.]

De keuze voor "segmentation fault" in het artikel is vreemd, dit wordt nergens genoemd (alleen "memory corruption").

Een segmentation fault kan niet altijd worden gebruikt om kwaardaardige code uit te voeren. Het is meestal een reactie van de kernel op onverwachte situaties (bijvoorbeeld schrijven naar geheugen waar het programma geen toegang tot zou moeten hebben).

Wanneer je bijvoorbeeld een zogenaamde "NULL pointer dereference" hebt crasht ("krijgt het programma een SIGSEGV signaal") het programma zonder code uit te voeren (onder normale omstandigheden). Dit kan niet worden gebruikt om code uit te voeren, maar het kan wel een denial of service als gevolg hebben (stel je een webserver voor).

Dit bovenstaamde geldt enkel voor userspace programmas. Wanneer er iets abnormaals gebeurd in de Linux kernel kan het niet zomaar besluiten om "effe de kernel zelf te killen". Een gevolg kan zijn dat er enkele data structures inconsistent zijn waardoor het systeem onbetrouwbaar is geworden en later nog eens kan crashen.

Maar ja, als je willekeurig kernel geheugen kan overschrijven kan dat inderdaad leiden tot uitvoer van willekeurige code.

[Verwijderd]

Segmentation fault betekent dat het programma probeert te zitten aan een segment in het (virtuele) geheugen, waar het helemaal niet aan hoort te komen.

Vaak komt dat door memory corruption. Door een bug schrijft een programma data ergens op de foute plek in het geheugen. Wanneer een ander deel van datzelfde programma daar data vandaan leest, heeft de huidige data niks meer te maken met de data die het daar verwacht. Bv het verwacht een geheugenlocatie-adres (een pointer). Maar daar staat random bits ipv een valide pointer. Het programma probeert dan data te accessen op een plaats waar het niet mag komen. Resultaat: de hardware/kernel ziet dat het proces aan een verkeerd segment probeert te komen, en stop het proces. Met een segmentation fault.

Dit kun je ook misbruiken om het programma jouw code te laten uitvoeren.

Je moet dan twee dingen doen.
1) Ergens in een buffer moet jouw malafide code staan. Je kunt dat bv doen door een pakketje te sturen dat ok lijkt, maar waar in het midden jouw code staat.
2) Je maakt gebruik van die bug. Je overschrijft ergens geheugen. Als je het goed doet, kun je er bv voor zorgen dat het programma niet naar een bepaalde subroutine springt, maar naar jouw kleine stukje code in die buffer. Wat je daar eerder in hebt geschreven.

Dus:
random memory corruption -> segmentation fault.
zorgvuldig uitgekiende memory corruption -> malafide code wordt uitgevoerd.

[harrydg]

Sta mij toe even te corrigeren:
de kernel/hardware ziet NIET dat het proces aan een verkeerd segment probeert te komen! De kernel doet gewoon zijn werk en gaat door. Er is geen enkele controle (op de meeste systemen) van wat waar geschreven wordt!!!
Er treedt dan ook ENKEL een segfault op als de "overschreven data" zorgt dat het process gewoon... fout gaat!
BIjvb je overschrijft het return adress van een functie (dat staat op de stack). Dit is gevaarlijk want de kernel springt gewoon terug naar het adres dat er op de stack staat. Overschrijf je dit adres "zomaar" is de kans dat je in "niet-code" uitkomt groot waardoor ... alles gewoon mis gaat => segfault
je kan echter perfect geheugen overschrijven ZONDER enig probleem
een voorbeeld van een buffer overflow die slechts "zelden" segfault en moeilijk te exploiten is (probeer maar, is plezant!): harry.enzoverder.be/oldulyssis/code/snprintfbug.c
Hier overschrijf je ook geheugen (slechts 1 byte, een nullbyte). DIt laten segfaulten is niet eenvoudig edoch exploitable.
Om maar te zeggen: je uitleg is redelijk OK, maar de kernel ziet niet dat er een verkeerd stukje geheugen overschreven is... hij "ervaart" dat. En als je je exploit goed schrijft, ervaart hij dat niet. (moest hij dat wel "zien", zou een buffer overflow niet kunnen werken, want inherent overschrijf je daar geheugen waar je niet aan zou mogen komen)

[MSalters]

Geen idee hoe deze reactie aan een +3 komt. "Er is geen enkele controle waar geschreven wordt" ? Er is wel degelijk een controle. Dat doet de CPU zelf. De methode daarvoor zijn de page tables en de MMU. Heel vroeg in de boot wordt de MMU geïnitialiseerd, die vervolgens virtuele adressen naar fysieke adressen vertaalt door ze in de goede page table op te zoeken. Als je een adres opgeeft wat niet in de page table voorkomt, dan geeft de MMU een page fault.

De Linux kernel ziet de pagefault van de MMU komen, en handelt die af. Normaal gesproken is de afhandeling een page-in van een geswapte pagina, maar als je een compleet onzinadres gebruikt dan heeft het OS ook geen diskmapping voor dat virtuele adres en krijg je een segfault (of een Oops, in kernel mode).

Het gaat pas goed fout als je naar geheugen schrijft waar je weliswaar naar toe mag schrijven, maar wat in gebruik is voor andere doelen. Heb je bijvoorbeeld een buffer en een return adres op de stack, dan mag je naar beiden schrijven. Maar als je de buufer overflowt, dan schrijf je buffer content naar een return adres, en dat veroorzaakt corruptie.

Die ene NUL byte ? Die segfault zelden omdat deze byte zelden in gebruik is; geheugenallocaties worden naar boven afgerond uit efficiency-overwegingen.

[cdwave]

De hele kernel draait in een enkele memory space. Toegang tot dit memory geeft je indirect toegang tot alles wat er op de machine gebeurt.

Eenmaal in kernel mode - bijvoorbeeld bij het afhandelen van USB events - staat het systeem in privileged mode en mag er veel meer dan alleen maar in het geheugen van de kernel schrijven.

Hou er wel rekening mee dat je voor deze "exploit" fysieke toegang tot de machine nodig hebt, je moet een malafide USB device erin steken. Dat kan dus niet vanaf een website, maar wel door een Tom Cruise hangend aan een paar draadjes boven je toetsenbord...
Je bankrekening loopt hier dus geen extra risico - als er iemand bij je USB poort kan, dan kan hij ook een keylogger of vergelijkbaar apparaa installeren. Wel kun je via deze exploit bijvoorbeeld tablets, mobieltjes, webTVs en vergelijkbare apparaten van extra features voorzien...

[aikebah]

Iets met congressen, reclame en USB-devices en ik zie een prima off-site attack vector.

[Gropah]

En op welke kernelversie is dit gedaan? De net gereleasede 3.11, of een oudere versie?

[.Peter.]

De kwetsbaarheid kan ik terugtraceren tot minstens 2.6.19 (2006). (het is mogelijk nog ouder, ik heb niet verder gekeken).

Voor de technici, volg parser->global.report_id in drivers/hid/hid-core.c. In de functie hid_add_field gebruikt wordt hid_register_report aangeroepen met die waarde (als unsigned int i.p.v. u8). Die functie leest/schrijft vervolgens zonder te morren:

static struct hid_report *hid_register_report(struct hid_device *device, unsigned type, unsigned id)
{
// <snip>
if (report_enum->report_id_hash[id])
return report_enum->report_id_hash[id];
// <snip>
report_enum->report_id_hash[id] = report;

[Reactie gewijzigd door .Peter. op 26 juli 2024 06:05]

[biteMark]

Jammer dat dit net na de release van een nieuwe Linux kernel bekend word...

[.Peter.]

Niet getreurd, over een week is er weer een nieuwe versie. Waarschijnlijk gaat 3.11.1 deze fix krijgen en wordt het gebackported naar eerdere versies.

[HMC]

juist niet jammer. Er gaan na de release heel veel mensen aan de slag.
Wat kan het wel, wat kan het niet? En dan de diepere inspecties, zoals deze.

[Verwijderd]

Onbegrijpelijk dat men nog steeds code durft schrijven die 'er van uit gaat dat...' Dit is nog steeds de oorzaak van de meeste exploits. Assumption is the mother of all disasters,.. Spijtig te moeten vaststellen dat dit zelfs anno 2013 nog niet is doorgedrongen bij veel coders...

[mashell]

Waar staat dat men hier "van iets uit gaat"? Als de specificatie voorschrijft dat er maximaal 255 blokken van type X komen en daarna 1 van type Y maar iemand stuurt je 256 blokken X dan ga je er 1 interpreteren als blok Y terwijl het een X is. Daar is niks aan te doen, zorgen dat de consequenties beperkt blijven is ook helemaal niet zo simpel en dat kan soms tot dingen leiden als een segmentation fault.

[ThomasG]

Als de specificatie voorschrijft dat er maximaal 255 blokken komen, wilt dat niet zeggen dat er geen 255+1 blokken kunnen komen (hetzij opzettelijk of door een fout). Als je dan als programmeur een aanname doet dat er maximaal 255 blokken kunnen komen, maar dit niet verwerkt hebt in de software, en er vervolgens geen fail-safe hebt ingebouwd als er wel meer blokken komen. Dan krijg je het zelfde soort kwetsbaarheid als bij de Linux-kernel dus het geval blijkt.

Ik weet niet precies hoe de code in elkaar steekt, maar stel je hebt een array met 255 elementen waar je deze datavelden in op slaat. Vervolgens wijs je elk dataveld een plekje toe in de array. Als je dan geen controle inbouwt om te kijken of je array vol is, d.w.z. je hebt de 255 datavelden bereikt, en wel een nieuw dataveld wilt toevoegen aan de array. Dan krijg je in talen als C, waar de Linux-kernel in geschreven is, geen runtime exception zoals bij bijv. Java. In plaats daarvan probeert het een stukje geheugen te schrijven wat niet bij de array hoort, wat in dit geval leid tot een segmentation fault.

[Reactie gewijzigd door ThomasG op 26 juli 2024 06:05]

[Dreeke fixed]

Klopt, zo werd er vroeger geprogrammeerd. Met de huidige list technieken gaan dit soort fouten gelukkig niet meer voorkomen.

[Sfynx]

Er zijn inderdaad leuke technieken om zulke dingen te voorkomen, maar de bijbehorende overhead is niet altijd gewenst in kernel space.

[SKiLLa]

List technieken gaan dit ook niet 'zomaar' voorkomen; een 'oneindige' List resulteerd ook in een DoS en kan ook tot een segmentatie-fout leiden. Daarnaast zijn low-level IO drivers vaak ook erg geoptimaliseerd en niets sneller dan een simpele Array. En waarom niet, zolang je maar een fatsoenlijk bound-check doet.

[Verwijderd]

Als het foutloopt omdat er (opzettelijk) meer blokken dan voorzien in de standaard worden verzonden, dan kan je duidelijk spreken van 'men gaat er zonder nadenken vanuit'.

Zoals ThomasG zegt, het is absoluut not-done om in een function of elders 255 blokken te voorzien omdat meer 'normaal niet kan'. En als er dan bewust of onbewust meer blokken komen gaat heel de boel de mist in...

Dit soort dingen kunnen alleen gebeuren als men 'van de veronderstelling uit gaat' in plaats van 'meet en weet' toepast...

[pe1dnn]

Dit soort dingen kunnen alleen gebeuren als men 'van de veronderstelling uit gaat' in plaats van 'meet en weet' toepast...

Je verondersteld een bewuste aanname of veronderstelling maar had men dat gedaan dan had men de fout niet gemaakt. Het probleem is niet dat dit destijds simpelweg niet de aandacht had en men er uberhaupt geen aandacht aangeschonken heeft. Met de kennis van nu is dat dom, met de kennis van toen was het onwetendheid. Het was niet voor niets een veel voorkomende fout.

Dit klinkt als een basale functie van USB wat doet vermoeden dat de code al stamt uit het begin van het USB tijdperk, zeg rond 1996 of zo. Code van toen zat stamp vol met potentiele bufferoverflows en men wist er ook van omdat je code meestal crashte als je buiten array of buffer grenzen kwam. Er werd ook op getest maar dan runtime bij het debuggen. Het was toen nog niet wijd en zijt bekend als beveilings exploid, dat is pas veel later gekomen. Boundary controles zaten dan ook vaak alleen in debug versies (die daardoor groter en zwaarder waren) maar niet meer in de release builds.

Er zijn ook jaren overheen gegaan voordat alle functies zoals sprintf waren vervangen zijn door de gelimiteerde varianten als snprintf.

Achteraf zeggen dat iets stom is, is te gemakkelijk. Eigenlijk hadden de oorspronkelijke schrijvers nog gelijk ook; uitgaande van 1996 heeft het dus 17 jaar gewerkt zonder problemen; maak maar eens een stuk software dat het 17 jaar zonder problemen doet. Ontwikkelaars van 17 jaar geleden of nog langer geleden afrekenen met inzichten van vandaag is pas stom.

Daarmee is overigens niet gezegt dat dit soort fouten niet gevonden en gefixed moeten worden, alleen dat je het de ontwikkelaars van destijds niet aan moet rekenen, er zijn niet voor niets al verschikkelijk veel van dit soort lekken gevonden. En wie weet hoeveel mensen die code al een bekeken hebben en het ook niet gezien hebben. Sterker nog, de huidige fout is gevonden door eerst teveel data te sturen en pas toen men met dat in het achterhoofd ging kijken heeft men het pas gezien.

[SKiLLa]

Ook in 1996 was een Buffer Overflow gewoon stom hoor; we hebben het hier niet over de 'primitieve' jaren 70 en 80. Happy-flow is gewoon korte-termijn denken, ook 17 jaar geleden.

PS: -1 wegens de waarheid vertellen ?!? Don't shoot the messenger peeps ...

[Reactie gewijzigd door SKiLLa op 26 juli 2024 06:05]

[Soldaatje]

Dat heeft te maken met hoeveel tijd je hebt om het een en ander uit te zoeken.
Als ik op mijn werk niet van bepaalde dingen uit ga dan gaat mijn baas uiteindelijk vragen waarom het drie à vier keer zo lang duurt.

[sanderv]

Ik denk dat het er meer mee te maken heeft dat mensen gefocused zijn op de happy flow. Men heeft het gevoel dat men daar op afgerekend wordt, en dat is op de korte termijn vaak waar. Er zijn kudos te verdienen door een gaaf feature aan de code base toe te voegen, en projectteams zijn ook vaak (commercieel) erg resultaatgedreven. Bugs rollen er later wel uit en komen vaak helaas niet op het conto van het projectteam. Er is ook nog altijd een bekend verhaal (blijkbaar in onderzoeken aangetoond) dat de beste en slechtste ontwikkelaars factoren tien en hoger verschillen in prestaties. Die slechtste ontwikkelaars committen ook wel eens code, en zijn niet altijd gekoppeld aan een beste ontwikkelaar die hun werk code reviewt. Zelfs in goed-georganiseerde projecten met verstandige mensen, worden er pragmatische beslissingen genomen. In veel omgevingen is het niet mogelijk om altijd voor kwaliteit te kiezen, ten koste van andere factoren (kwaliteit, tijd en geld).

[Verwijderd]

Volgens mij gaat er inderdaad het meeste mis op organisatorisch gebied.

Op het technische vlak valt ook wel het een en ander te verbeteren. Zo wordt voor de kernel de programmeertaal C gebruikt. Vanuit security-perspectief niet de meest geschikte taal (ook niet vanuit het perspectief van functionele bugs overigens). Een functionele taal als Haskell zou bijvoorbeeld veel veiliger zijn. Maar ja, dan ga je weer knagen aan de performance.

Idealiter gebruik je een programmeertaal waarin je de assertions van je programma bewijsmatig vastlegt. Uiteraard kunnen er zelfs dan nog fouten optreden, maar de kans is wel veel kleiner. De performance van je code kan dan wel groot zijn (het bewijs van je code hoeft immers niet elke keer gecontroleerd te worden). Echter, dan ga je weer knagen aan de ontwikkeltijd. Bovendien moeten programmeurs dan veel meer expertise hebben (je hebt dan eerder "wiskundigen" nodig dan "programmeurs").

[freaq]

er is natuurlijk wel een verschil tussen een programma, en een kernel van een operating system, al kan ik me voorstellen dat al dat soort check ook veel performance zouden kunnen gaan kosten als ze constant gedraait zouden worden.

[SuperDre]

Blijkbaar heb jij nog nooit in productie gewerkt. Naast het feit dat je soms niet alles kunt bedenken (zeker niet onder grotere druk), maar vaak genoeg wordt er voor gekozen om bv controle op invoer pas achteraf in te bouwen ipv op het moment dat je het betreffende veld/invoer gaat toevoegen (tja, ik zie het helaas ook gebeuren bij ons op het werk bij het nieuwe project)..
Soms is het gewoon van hogerhand omdat ze snel iets willen uitbrengen.. En soms is het gewoon omdat iemand dus niet beter weet.. En soms zit je gewoon met legacy code..

[Verwijderd]

Ik heb al genoeg code geschreven die in produktie is of moet gaan en een van mijn prioriteiten is check and double check. Zeker wat betreft input. Ik neem nooit zomaar aan dat ik X of Y als input ga krijgen, ook al is dat de bedoeling.

IMHO is en blijft dat een grote fout, en is er geen enkel excuus voor te vinden. En als er mensen van mening zijn dat dit soort 'fouten' te begrijpen zijn omdat men onder tijdsdruk werkt of de controle van de input wel 'achteraf' gaat doen dan ben je sowieso heel verkeerd bezig volgens mij.

[Aikon]

Het feit dat dit nu ontdekt wordt wil niet zeggen dat ook dit jaar deze fout in Linux is geslopen. Voor hetzelfde geld zit deze fout er al in sinds Linux usb ondersteund.

Zoals je zelf al zegt: assumption is the mother of all fuckups.

[Reactie gewijzigd door Aikon op 26 juli 2024 06:05]

[MSalters]

Dan heb jij niet serieus geprogrammeerd.

Het is behoorlijk redelijk om er vanuit te gaan dat je maximaal 256 "dingen" kunt sturen, als elk "ding" een unieke 8 bits ID heeft. Wiskundigen "gaan er van uit" dat er geen gehele getallen bestaan tussen de 0 en de 1.

Overigens heeft ook dit artikel een one-off error: "De kernel beperkt het aantal datavelden dat in deze gebeurtenissen voor mag komen tot 256. Een apparaat dat meer dan 255 van deze zogenaamde report-id's stuurt, veroorzaakt een segmentation fault in Linux." Als een apparaat er nu precies 256 stuurt, dan is dat dus niet beperkt en wel meer dan 255.

De oorzaak van de one-off error is zoals gebruikelijk dat computers bij 0 beginnen te tellen: de fout ontstaat bij een report ID van 256, wat de 257'ste report ID is.

[Verwijderd]

Tja, het is ook een beetje inherent aan de programmeertaal. C is heel direct en dus ook snel met memory, maar niet safe. Ja, tegenwoordig krijg je een random geheugen toegewezen van een malloc aanvraag, maar buffer overflows zijn toch typisch iets voor C.

[SuperDre]

maarja, aan de andere kant, liever direct en snel toegang tot geheugen waardoor een programma lekker snel draait, dan een trage 'veilige' allocatie van geheugen waardoor het programma als dikke stront draait (veel .NET/Java applicaties/garbagecollecting-based frameworks).. Want ook met C kun je gewoon fatsoenlijk programeren zonder dat er problemen zouden zijn.

[Reactie gewijzigd door SuperDre op 26 juli 2024 06:05]

[Verwijderd]

Dit wordt toch JIT compiled? Wat is daar dan indirect aan? Er zit toch geen 'laag' tussen, ofzo?

[Verwijderd]

Je krijgt gelijk. Zoals hieronder door .Peter. is aangetoond blijkt het simpelweg te gaan om het ontbreken van een check. En lijkt dus op een slordigheidje.

En met de rest van jouw argumenten ben ik het ook eens. C blijft een fantastische taal.

[MSalters]

Nee, dit is inherent aan het feit dat je een kernel programmeert. Als je dat in elke willekeurige andere taal zou doen die geschikt is voor kernels, dan had je hetzelfde probleem. Kernels zijn per definitie niet safe, juist omdat ze voor de safety van de rest van het systeem verantwoordelijk zijn.

Dat is overigens ook de reden voor micro-kernels. Maak de eigenlijke kernel zo klein en simpel mogelijk, en doe alle andere OS dingen buiten de kernel. Dat beperkt de mogelijke consequenties van bugs in het OS, en een kleine simpele kernel is veel beter te testen.

[OrangeTux]

Het is een behoorlijk lek. Het is mogelijk eigen kernel te booten.

quote: Kees Cook

Memory write via arbitrary heap array index. This is the most serious,
IMO, as it allows (on 32-bit) access to the entire memory range (the
index is unsigned 32 bit). [...] Still, this could
almost certainly be turned into full kernel execution given enough
study.

[mad_max234]

Je kan dit met bijna elke micro controller doen, usb kan je softwarematig implanteren in elke controller die snel genoeg is, teensy is niks anders dan AVR op pcb met usb poort erop(dit geval hardwarematig).

Pak elke willekeurige avr, zet er vusb op soldeer er usb poort aan en verander id in 256 of hoger, klaar is je aanval apparaat. Je kan bijvoorbeeld een attiny45 pakken voor 1.50 euro en die is prima is staat om dit uit te voeren.

[Reactie gewijzigd door mad_max234 op 26 juli 2024 06:05]

[4play]

Dat hadden ze beter in 3.11 kunnen patchen

[HMC]

Als u op de Windows versie doelt, dan heeft u helemaal gelijk.

Er zullen altijd vulnerabilities in elk OS zitten.
Het mooie aan Linux (en aanverwanten) is dat deze naar buiten worden gebracht, ASAP.

[SuperDre]

Onzin, ook bij Linux zijn er nog genoeg vulnerabilities die nog steeds geheim gehouden worden.

[Zer0]

het wordt meteen gepatched nadat het gevonden is.

Als het gevonden wordt door goedwillende personen wel ja, maar of iedereen gevonden gaten rapporteert kun je niet garanderen.

[bbob]

Ach ja sommige mensen schijnen niet te weten dat er bedrijven zijn dit dit soort kwetsbaarheden verkopen voor veel geld.

Hier op tweakers kon je ook lezen dat de NSA miljoenen uitgeeft voor deze exploits. dus denken dat linux vrij is hiervan is je kop in het zand steken.

Reken maar dat ze er zijn en dat ze door bedrijven, overheden, criminelen met veel geld zorgvuldig misbruikt worden.

[Verwijderd]

* ey!, pssssssst! exploit kopen?* http://www.vupen.com/english/

[digifan]

Het gaat erom/punt is of het Linux kernel team het geheimhoud of derden.
In het eerste geval is het verwijtbaar aan "Linux" in het tweede niet.
Het is bijv. wel bewezen dat MS wist van lekken zonder ze te dichten.
Bij Linux is dat imo niet het geval, bovendien kan de vinder van het lek het zelf oplossen als hij dat wil, de bron is nl open.

[3dfx]

En hoef je niet eerst 100 updates door te voeren cq. dependencies te checken voordat de betreffende kwetsbaarheden werken?

Wow, daar zouden de mensen die drivers voor Linux schrijven misschien nog wat van kunnen leren!