Afhandeling van securitylekken in de Linux-kernel

Theori was bij geen van beide betrokken en ook in die twee gevallen verliep de openbare bekendmaking allesbehalve soepel. De oorzaak van de problemen ligt in fundamenteel verschillende opvattingen over hoe je met beveiligingsproblemen in de Linux-kernel moet omgaan.

Ter verduidelijking wat achtergrondinformatie over de gang van zaken: het Linux-kernelteam brengt om de paar weken een nieuwe kernel uit, maar veel gebruikers willen niet met zo’n frequentie nieuwe kernels installeren. Ze zijn onder andere bang dat de updates problemen op hun systemen veroorzaken en willen dat risico zo min mogelijk lopen.

Bovendien passen sommige Linux-distributies de door hen geleverde kernels uitgebreid aan. Vooral enterprise-distributies hebben bovendien certificeringen nodig en beloven de ABI (Application Binary Interface) voor applicaties te behouden, waardoor ze niet zomaar kunnen overschakelen naar nieuwere kernelversies.

Veel Linux-distributies leveren daarom bewust oudere kernelversies die ze zelf onderhouden en aanvullen met noodzakelijke beveiligingspatches. Voor dat laatste werken de distributies onder andere samen via een mailinglijst genaamd linux-distros (zie de link bij dit artikel).

De kernelontwikkelaars zijn daarentegen voorstander van een heel ander model. Ze zijn ervan overtuigd dat het – in ieder geval voor hen – onmogelijk is om uit de enorme hoeveelheid bugfixes juist die te selecteren die veiligheidsrelevant zijn. De gebruiksscenario’s van Linux zijn te verschillend en het is te moeilijk in te schatten of er echt geen scenario bestaat waarin een concrete fout niet ook een beveiligingslek is.

Daarom proberen de kernelontwikkelaars simpelweg alle bugs zo snel mogelijk op te lossen, en als je een veilig systeem wilt, moet je altijd de nieuwste kernel gebruiken. Ze zien weinig nut in het idee om een systeem met een oude kernel te beveiligen door uit de dagelijkse stroom van bugfixes alleen die te selecteren die beveiligingslekken dichten en ze naar de oude kernel over te zetten.

Het door Linux gedocumenteerde meldingsproces voor beveiligingslekken (zie de link bij dit artikel) voorziet ook niet in iets dergelijks. Kortom: als je een lek vindt, moet je dat melden aan de verantwoordelijke kernelbeheerder, waarna het in nog onderhouden kernels verholpen wordt.

De Linux-ontwikkelaars van het beveiligingsteam zien het echter niet als hun taak om beveiligingslekken bekend te maken of te coördineren dat de fixes tijdig in de kernels van de afzonderlijke distributies opgenomen worden. Zelfs de mogelijke toekenning van een CVE-nummer wordt niet door het beveiligingsteam geregeld, maar door een aparte groep die achteraf bekijkt of het opgeloste probleem een CVE-nummer verdient.

In de documentatie over het meldingsproces staat wel dat de publicatie van beveiligingsrelevante fixes in de distributiekernels doorgaans via de mailinglijst linux-distros afgestemd wordt, maar er wordt in scherpe bewoordingen gewaarschuwd om de distributies niet via de lijst vooraf te wijzen op beveiligingsrelevante bugs: “Het kernelbeveiligingsteam raadt ten zeerste aan […] geen contact op te nemen met de mailinglijst linux-distros voordat de beheerders van de betreffende code een oplossing geaccepteerd hebben.”

Bovendien moet je de eisen die het contact met linux-distros met zich meebrengt voor de melder en de kernelcommunity volledig begrijpen. Dat is net zo afschrikwekkend als het klinkt. In het debat over Copy Fail zei de vooraanstaande kernelontwikkelaar Greg Kroah-Hartman: “Ik wil niet dat iemand zich tot linux-distros wendt, want dat levert alleen maar meer problemen op dan het waard is.”

De communicatie tussen het kernelbeveiligingsteam en linux-distros is inderdaad al niet eenvoudig, simpelweg omdat de twee groepen bij embargo’s met verschillende deadlines werken. Half maart had het gerenommeerde beveiligingsbedrijf Qualys daarom ook aangekondigd dat het in de toekomst niet meer via linux-distros met andere distributeurs wil afstemmen en “de openbaarmaking van kernelkwetsbaarheden alleen met het Linux-kernelbeveiligingsteam” wil bespreken.

Naar dit besluit verwees ook Theori toen men probeerde de eigen aanpak uit te leggen tegenover de opkomende kritiek. Men was ervan uitgegaan “dat distributies over mogelijkheden beschikten om zich te informeren over veiligheidsgevoelige [fouten in de kernel].”

Maar een beveiligingslek met de omvang van Copy Fail, inclusief exploit, openbaar maken en zomaar beweren dat “de meeste grote distributies” al fixes leveren, is toch wel meer dan naïef – zeker voor een bedrijf als Theori, dat zich professioneel bezighoudt met IT-beveiliging.

Hoe dan ook, die aanname was gewoonweg verkeerd en het lek was er nog steeds – juist omdat de kernelontwikkelaars niet met de distributies afstemmen.

Distributies die niet zomaar altijd een actuele kernelversie kunnen of willen leveren, staan dus voor de lastige taak om uit de stortvloed aan bugfixes die te selecteren en in hun kernel over te nemen die voor hun klanten veiligheidsrelevant zijn. Dat is niet alleen lastig vanwege de hoeveelheid patches, maar ook omdat de kernelontwikkelaars niet in staat zijn om beveiligingsrelevante patches apart te markeren.

Zoals gezegd vinden ze dat vrijwel elke bugfix in de kernel potentieel van belang is voor de veiligheid, en dat een dergelijke markering daarom zinloos zou zijn.

Ook de – sowieso pas achteraf gepubliceerde – CVE-nummers zijn geen goed signaal. Enerzijds worden ze door Linux op grote schaal toegekend, zelfs situaties die alleen betrekking hebben op een waarschuwing van de kernel krijgen een CVE-nummer.

Er is namelijk de kerneloptie panic_on_warn, waarmee dergelijke waarschuwingen tot een crash leiden. Crashen beïnvloedt op zijn beurt de beschikbaarheid van systemen, een expliciet doel van IT-beveiliging, dus is een waarschuwing uiteindelijk ook veiligheidsrelevant.

Aan de andere kant dekken CVE-nummers ook niet alle bugfixes die essentieel zijn voor gebruikers. Als een bug bijvoorbeeld tot een enorm gegevensverlies leidt, maar voorkomt in situaties die niet door een aanvaller kunnen worden misbruikt, is er geen sprake van een beveiligingslek – tenminste niet volgens de definitie van cve.org die bepalend is voor CVE-nummers.

Daarom kennen de Linux-ontwikkelaars voor dat soort bugs geen nummers toe, hoewel in ieder geval Greg Kroah-Hartman dat graag zou doen (zie de link bij dit artikel).

Bovendien geven de kernelontwikkelaars natuurlijk alleen CVE-nummers aan problemen in de kernels die ze zelf nog onderhouden. Linux-distributies bieden echter vaak ook andere, meestal nog aanzienlijk oudere kernelversies, waarvoor ze zelf de verantwoordelijkheid dragen.

Soms vullen de Linux-ontwikkelaars CVE-nummers wel aan met kwetsbaarheidsbeoordelingen volgens de CVSS-standaard, maar omdat ze dat zeker niet altijd doen, zijn ook de CVSS-waarden geen goede indicator om beveiligingsrelevante bugs op te sporen.

We hebben verschillende grote distributeurs gevraagd hoe ze Linux-bugfixes analyseren en ervoor zorgen dat ze alle veiligheidsrelevante fixes in hun kernel opnemen. Alleen Red Hat en SUSE hebben gereageerd. Die laatste benadrukten het belang van een “goed gestructureerd proces voor het afhandelen van kwetsbaarheden”.

Hoe hun proces er precies uitziet, heeft SUSE echter niet uitgelegd en ze wezen er alleen op dat het “extern is gecontroleerd door een van de meest gerenommeerde overheidscertificeringsinstanties”. In het algemeen lijkt men bij SUSE tevreden te zijn met het proces, ook in het geval van Copy Fail. Ze zeggen dat ze de eerste Linux-distributeur zijn die Copy-Fail-fixes voor hun hele productassortiment uitgebracht hebben.

SUSE kon inderdaad al op 3 mei, een zondag, melden dat Copy Fail in zijn producten verholpen was. Dat is slechts vier dagen na de veelbesproken bekendmaking van het beveiligingslek, maar wel meer dan een maand nadat het probleem in de huidige kernel opgelost was. Het tijdsbestek lijkt dus meer te spreken voor de reactiesnelheid van SUSE dan voor de competentie om relevante bugfixes te herkennen en tijdig over te nemen.

Red Hat verklaarde alle door Linux gepubliceerde CVE’s te beoordelen en potentiële bugs te analyseren met een reeks tools en niet nader omschreven methoden. In de toekomst wil men in die processen nog meer AI inzetten dan tot nu toe.

Red Hat begon op 4 mei met het uitrollen van fixes voor Copy Fail, hoewel men naar eigen zeggen al op 22 april, bij de CVE-publicatie van de kernel, erop geattendeerd was. Ze hadden het beveiligingslek echter als ‘matig’ ingeschat en de urgentie van de oplossing pas verhoogd na de publicaties op 29 april.

Het is misschien niet zo gek dat SUSE en Red Hat, en blijkbaar ook geen enkele andere distributie, niet op de hoogte waren van het beveiligingslek vóór de publicatie van de website over Copy Fail. Volgens Kroah-Hartman krijgt het beveiligingsteam ‘de hele tijd’ meldingen over kwetsbaarheden zoals Copy Fail, oftewel beveiligingsproblemen waardoor aanvallers hun rechten kunnen uitbreiden.

Copy Fail was op zich niets bijzonders, maar werd pas een opzienbarende zaak omdat de ontdekkers hun vondst inclusief een proof-of-concept voor een exploit publiceerden.

Theori moet die kritiek wel slikken: als je wilt pronken met eigen vondsten en voorbeeld-exploits, moet je er eerst voor zorgen dat er daadwerkelijk patches uitgerold zijn – en dat niet zomaar beweren, in de veronderstelling dat iedereen zijn huiswerk wel gedaan zal hebben.

Een exploit niet meteen aan de grote klok hangen, biedt in tijden van AI echter maar heel weinig bescherming – als die er al is. Aanvallers zijn immers niet afhankelijk van opvallende websites om achter beveiligingslekken te komen. Net als de distributeurs kunnen ook zij de stroom aan bugfixes in de kernel analyseren en proberen de beveiligingskritieke te ontdekken.

Dankzij AI-systemen kost dat relatief weinig middelen. Er hoeft maar één zo’n bugfix aan de scans van een distributeur te ontsnappen en zijn Linux-versie is al kwetsbaar, waardoor de aanvallers in die race een inherent voordeel hebben.

De aanpak om relevante patches te selecteren en naar een oude kernel over te zetten, lijkt daarom steeds onrealistischer – de zegen van de kernelontwikkelaars heeft die aanpak sowieso nooit gehad.

Aan de andere kant zijn er, zoals gezegd, geldige redenen waarom veel Linux-gebruikers vaak wisselende kernels afwijzen. De betrokken partijen zullen in actie moeten komen om gevallen zoals Copy Fail in de toekomst te voorkomen, maar een oplossing lijkt momenteel nog niet in zicht.

Ondertussen vragen zowel Red Hat als SUSE dat ontdekkers van beveiligingslekken de extra moeite nemen om, nadat er een fix in de kernel is, ook de distributies via linux-distros op de hoogte te brengen van hun bevindingen. Dat gaat Qualys in de toekomst ook weer doen, zoals ze tijdens de discussie over Copy Fail hebben laten weten.

Sylvester Tremmel en Noud van Kruysbergen