Linux heeft stilletjes de wereld veroverd. Het is nu de drijvende kracht achter cloudapplicaties en diensten met enorme datacenters die dit afleveren en het is het OS bij voorkeur voor internetverbonden apparaten (IoT) en mobiel (Android). Zelfs systemen die het internationale ruimtestation doen dat met behulp van Linux.

 Kernelbeveiliging heeft de hoogste prioriteit, omdat Linux zo alomvertegenwoordigd is. Een issue in de kernel heeft een enorme impact die door vrijwel iedereen wordt gemerkt. Het vinden van bugs is maar één aspect van de kernel, nog belangrijker is het flexibel verstevigen ervan zodat de Linux-basis bestand is tegen aanvallen.

“Eerlijk gezegd lopen updates altijd achter de feiten aan”, zegt Linux-bedenker en pionier Linus Torvalds. “Een van de redenen dat we werken aan het verstevigen van de kernel is om updates van minder kritiek belang te maken, zodat zelfs als er een securitylek is, de beschermende aanpak ervoor zorgt dat de impact niet zo acuut is.”

Er zijn een heleboel mensen die grondig naar de kernel kijken om kwetsbaarheden te vinden en te repareren. Vorig jaar werden er meer dan 200 gevonden, inclusief een kritiek use-after-free-gat waarmee aanvallers zonder authenticatie code konden uitvoeren in kernels ouder dan versie 4.5.2 (CVE-2016-7117). In januari loste Android een bufferoverloopissue op in kernel 3.18 (CVE-2016-8459) en in de aankomende versie van de kernel, 4.10, moeten meer security-fixes zitten.

Maar het oplossen van bugs is geen strategie waar je de oorlog mee wint, omdat veel systemen die Linux draaien niet worden bijgewerkt naar een nieuwe kernel. Kwetsbaarheden die later worden opgelost, worden geïmplementeerd op servers en pc’s, omdat IT’ers de updates direct van distributiemakers krijgen.

Dat geldt niet voor Android en veel IoT-apparatuur, die laat of zelfs helemaal geen updates krijgen krijgen. Apparatuur als routers, switches en IP-camera’s zijn lang verbonden met netwerken en worden niet veel bijgewerkt. Er zijn ook maar weinig mensen die eraan denken om regelmatig iets als internetverbonden garagedeuren bij te werken.

“Het kan heel frustrerend zijn om te zien dat mensen oude en waarschijnlijk onveilige gebruiken, enkel en alleen omdat de leverancier het lastig of onmogelijk heeft gemaakt om updates op een normale manier uit te rollen”, zegt Torvalds. “Misschien was het omdat ze ergens een stukje hardware gebruiken met een propriëtaire driver of eentje die niet beschikbaar meer is in een later stadium – er is ergens wel een misbaksel die geen updates krijgt.”

Hoe verklein je het tijdsgat tussen het repareren van gaten en de daadwerkelijke uitrol van de fix op Linux-systemen? Een idee is live-patchen, waarbij kritieke fixes worden gedistribueerd zodra te beschikbaar zijn.

Verschillende distributies gebruiken verschillende aanpakken: Ubuntu 16.04 gebruikt Kernel Live Patch Core, RHEL heeft kpatch, Oracle Linux ksplice en Suse kGraft. Het idee is hetzelfde: de machines worden op kernelniveau beveiligd terwijl de uptime niet wordt bedreigd. Het is vooral handig in sterk gecontaineriseerde omgevingen, omdat meerdere containers dezelfde kernel gebruiken.

CoreOS is recent ook begonnen aan live patching – ze noemen het daar zelfsturende updates – met Tectonic, een combinatie van orchestratiettol Kubernetes en de containergebaseerde Linux-distributie van CoreOS: Container Linux. Het doel is om beveiligingpatches meteen uit te rollen als ze gebouwd zijn, zonder te wachten tot ze upstream in de kernel worden verwerkt of eerst intern geverifieerd moeten worden.

Kubernetes is ontworpen voor gedistribueerde omgevingen, wat beveiligingspatches heel complex maakt, zegt CoreOS-CTO Brandon Philips. Geautomatiseerde updates zorgen ervoor dat clusters actueel en beveiligd zijn zonder dat het downtime oplevert. Uitrol over clusters kan potentiële problemen in de kiem smoren, maar het is geen optie voor veel Linux-systemen. Daarom richten beveiligingsspecialisten zich steeds meer op de kernel zelf om diens inherente beveiliging te verbeteren.

Het verstevigen van de kernel is effectief, omdat het verbeterde beveiliging voor de host levert. Het voorkomt verschillende aanvalsmethodes, door bijvoorbeeld de geheugenadressering die een applicatie kan aanspreken te beperken om zo bufferoverloopaanvallen te voorkomen of door toegangscontrole te implementeren om superuser-rechten in te trekken.

Maar Self-Protection gaat nog een stap verder, vertelt Google-ontwikkelaar Kees Cook die aan het hoofd staat van het Kernel Self-Protection Project (KSPP) en gaat om “het bouwen van een kernel die aanvallen weerstaat”. Het project bestaat iets meer dan een jaar en is een plek waar Linux-ontwikkelaars technieken voor zelfbescherming bespreken, testen en documenteren.

Dit is anders dan de kernel gebruiken om de userspace te beschermen, maar om de kernel te gebruiken om het moeilijker te maken exploits te benutten. Dat is meer dan toegangscontrole (als in SELinux) of het verkleinen van het aanvalsoppervlak (als in seccomp) maar ook om het voorkomen van het categorieën bugs zodat als een fout opduikt, hij niet te misbruiken is in een versie van de kernel die niet is bijgewerkt. Omdat veel exploits meerdere kwetsbaarheden misbruiken, zorgt het demonteren van één probleem voor een effect in de hele killchain.

Beveiligingsgaten kunnen jarenlang in code zitten voordat ze worden opgemerkt. Cook keek naar de tijd die er zat tussen de introductie van kritieke en belangrijke gaten in de kernel en het moment dat ze werden ontdekt en die tijd zat tussen de 3,3 en 6,4 jaar. Aanvallers kijken zorgvuldig door elke commit op zoek naar een gaatje en vinden kwetsbaarheden ver voordat beveiligers ze opmerken.

Dat een kwetsbaarheid in code niet is gevonden, betekent helaas niet dat hij niet bestaat of dat niemand ervan weet. Kernelkwetsbaarheden hebben blijkbaar een lange levensduur, dus het is verstandig om de kernel zodanig te bouwen dat het gedurende die jaren door zijn ontwerp aanvallen kan weerstaan.

 Het is onmogelijk om alle categorieën van bugs te elimineren, maar KSPP kijkt al naar integeroverflow, heapoverflow, format string-injectie, kernelpointer-lekken, ongeïnitaliseerde variabelen, directe kernel-overschrijving, overschrijving van functie-pointers, het toegang verkrijgen van userspace-geheugen vanuit de kernel en ROP. De kernel biedt al beveiliging tegen stackoverflows sinds 2.6.30 met -fstack-protector in de GCC en -fstack-protector-strong is toegevoegd in versie 3.14.

Veel van het zware werk is al verricht door teams bij Grsecurity en PaX, maar de code is nog niet aan de kernel toegevoegd om verschillende redenen. Met het project vindt Cook geen splinternieuwe beveiligingstechnologie uit, maar probeert hij bestaande – en breder geaccepteerde – code toe te voegen aan de kernel, zoals:

  • Met geheugenbescherming Privileged Access Never (PAN) wordt userspace-data niet aangesproken, tenzij het specifiek is ingesteld. De PAN-hardwarefeature die door Grsecurity werd geëmuleerd voor de ARM-architectuur in kernel 4.3.
  • Geheugenbescherming met ASLR is toegevoegd in kernel 4.5. Kernel-ASLR (KASLR) is in diverse architecturen sindsdien toegevoegd, maar dat is een beetje een wapenwedloop omdat er steeds nieuwe bypasses worden bedacht.
  • Read-only data (RODATA) werd in versie 4.6 verplicht voor x86-architecturen, ARMv7+ en arm64.
  • Versie 4.8 bevatte de toevoeging van GCC-plugin-infrastructuur om plugins van Grsecurity/PaX te gebruiken in de kernel.
  • Stack-bufferoverloop werd aangepakt in kernel 4.9 met stack guard pages tussen kernel-stacks. Als er nu voorbij het einde van de stack wordt geschreven in x86_64-architecturen, stopt de kernel onmiddelijk in plaats van de schrijfbewerking verder uit te voeren.

Brad Spengler van Grsecurity stelde in 2010 een lijst samen van Linux-kernelwijzigingen die het duurder maakt voor aanvallers om kernelexploits in te zetten, omdat die zich onvoorspelbaar gedraagt (PDF). Volgens Cook zijn diverse items van die lijst al aangepakt, zoals het beschermen van gevoelige data door de vsyscall shadow map volledig te verwijderen, het schrappen van lees-, schrijf-, en uitvoer-mapping uit de kernel, en het poorten van PAX_USERCOPY dat kernelobjecten controleert.

Veel van de items zijn nog steeds in ontwikkeling, zoals het werk aan ASLR en KASLR, en volgen Cook moet er nog steeds genoeg gebeuren. Bedrijven die Grsecurity gebruiken hebben al baat gehad bij de self-protection-technologieën. Het verschil zit hem voornamelijk in het feit dat als deze technologieën niet zijn toegevoegd aan de kernel zelf, de meeste organisaties die Linux gebruiken er niet eens van weten.

Het aantal distributies dat de patches toevoegt groeit, maar het is vooral nog aan securitybewuste IT’ers en organisaties om Grsecurity en PaX toe te voegen om hun systemen te beveiligen. Dat is nog niet gebeurd bij het gros van de organisaties. Door de verbeteringen toe te voegen aan de kernel, wordt een groter aantal gebruikers bediend met de beveiligingsmiddelen.

Wat Torvalds betreft is self-protection niet een feature die alleen in de Linux-kernel moet worden verwerkt. Hij denkt dat de kernel ook beter wordt beschermd met de hardwarebescherming van recente high-end x86-, x86_64- en ARMv7-processoren. Bijvoorbeeld NX, de technologie die geheugenadressen beschermt tegen uitvoerbare code, wat bijvoorbeeld bufferoverloopaanvallen voorkomt. “De krachtigste self-protection-methodes voor de kernel zijn eigenlijk hulpmiddelen van hardware”, zegt Torvalds.

Nog een voorbeeld was SMAP/SMEP (supervisor mode access/execute protection) maakt het lastiger om de kernel door een softwarefout userspace-data aan te laten spreken. SMAP was “iets waar wij Linux-kernelmensen om vroegen”, omdat het vrij duur is om dit in software te bouwen, maar goedkoper voor hardware omdat de processor al de benodigde informatie heeft. “Het duurt lang voordat nieuwe CPU-features daadwerkelijk in de handen van consumenten komt”, zegt Torvalds, “en SMAP zit enkel in de recentste Intel-CPU’s, maar het is een goed voorbeeld van technologie die een hele categorie van aanvallen kan voorkomen.”

Google stort zich ook op zulke self-protection voor Android, met sterkere geheugenbescherming en het beperken van kernelruimtes waar aanvallen kunnen worden uitgevoerd. Sinds Android Nougat volgt Google Grsecurity met het verwijderen van directe geheugenmapping vanuit de kernel naar userspace, wat de mogelijkheden voor aanvallers verkleint om de kernel te kapen en malafide code te gebruiken die in virtueel geheugen is opgeslagen.

Secties van het geheugen zijn gescheiden, zodat een kwetsbaarheid in één deel niet kan leiden tot issues in anderen. Met het segmenteren van de kernel in read-only- en read-write-sectoren, beperkt dat de mogelijkheden van malware om iets uit te voeren. Ook zijn de perf-functies standaard uitgeschakeld, om bepaalde aanvalscenario’s uit te sluiten. Perf kan alleen nog worden aangesproken in developer-modus. Met Android Nougat is de seccomp-sandbox die Nexus-apparaten gebruikten verplicht geworden voor alle toestellen.

De userspace wordt lastiger aan te vallen en daarom richten hackers hun aandacht steeds meer op de kernel. Kernel-ontwikkelaars lopen achter de feiten aan, omdat ze van tevoren niet weten welke softwarebug aanvallers op de korrel zullen nemen. Veel van de fouten zitten niet eens in de kernel, maar in third-party code zoals drivers. Met self-protection wordt de kernel veiliger omdat het niet uitmaakt waar die bug zich bevindt.

Het snel pletten van bugs is altijd een strategie waarbij je achter de aanvallers aanloopt. Het blijft een belangrijk element voor beveiligers, maar Linux-beveiliging vereist meer, vooral omdat apparaten die niet te upgraden zijn (bijvoorbeeld IoT-gadgets) beveiliginsgaten bevatten. De kernel moet meer geautomatiseerd worden en self-protection bevatten om aanvallen tegen te gaan.

“We zijn er nog niet helemaal”, zegt Torvalds. “Absolute beveiliging bestaat niet, dus het zal nooit honderd procent veilig zijn, maar er werken mensen aan het verbeteren van de beveiliging in de praktijk.”