Linux-kernelbug: 5 brandende vragen

Linux-kernelbug

Linux-kernelbug

Ai, een kwetsbaarheid in de Linux-kernel! Waarom is het belangrijk dat deze bug even op de radar staat en hoe kwetsbaar zijn mobiele apparaten? 

5 brandende vragen over de Linux-kernelbug

Beveiligingsbedrijf Perception Point vond een tijdje geleden een potentiële kwetsbaarheid in de Linux-kernel. Door misbruik van een feature die sleutels beheert, kunnen aanvallers authenticatiesleutels bemachtigen en zo code uitvoeren als rootgebruiker. Hoe groot is dit probleem precies?

1. Wat is er aan de hand?

Het gaat hier om een aanval op het geheugen, specifiek op het stukje geheugen dat de keychain beheert. Een teller in de kernel houdt bij welke code wordt gebruikt om een specifiek object aan te spreken. Als die teller 0 bereikt – en het object dus niet meer wordt aangesproken – wordt het stuk geheugen gesaneerd en vrijgegeven.

Door een bug in het beheer van de keychain – die koppelingen bevat naar authenticatiesleutels van de gebruiker – kan de teller van het keychain-object naar nul worden geforceerd, waardoor het geheugen onterecht wordt vrijgegeven.

Aanvallers kunnen via een exploit verwijzingen uit het na de aanval vrijgegeven stukje geheugen vissen om sleutels te bemachtigen. Een Use After Free-kwetsbaarheid dus. Dankzij deze bug is het mogelijk dat een aanvaller die een beperkt account heeft bemachtigd zijn of haar rechten escaleert naar rootrechten om zo toegang te krijgen tot het hele systeem.

2. Wat is er precies kwetsbaar?

De keychain-configuratie met deze kwetsbaarheid is in 2012 toegevoegd aan kernel 3.8 en daarmee zijn alle Linux-distributies in principe kwetsbaar. Maar de standaardconfiguratie van de kernel bevat de instelling waarmee de keychain-kwetsbaarheid vervolgens wordt aangesproken niet. (Hetzelfde geldt voor de standaardconfiguratie van de kernel in Android, zie punt vier.) Dat betekent dat losse producenten, OEM’s en makers van distributies, er zelf voor gekozen moeten hebben de feature te implementeren.

Wat overigens ook belangrijk is om even bij stil te staan: zoals in de reacties op diverse fora is te zien, interpreteren veel gebruikers kernelversie 3.10 als 3.1, wat een versie is van vóór het kwetsbare 3.8. Maar in de kernel-nummering volgt 3.10 op 3.9. Zo zit Android 6.0 (Marshmellow) op kernelversie 3.18.

Kortom, ook de individuele distributies lossen het probleem op. Debian heeft alvast patchesuitgebracht voor Wheezy en Jessie en Canonical heeft patches voor Ubuntu. Bij Red Hat is momenteel een patch in ontwikkeling. Mocht je meer patches hebben zien langskomen, laat het weten – dan voegen we hem toe. Niet voor elk kwetsbaar systeem is al een patch beschikbaar, maar er zijn gelukkig een hoop mitigatiefactoren voor zowel Linux-servers als mobiele apparaten (zie punt drie).

3. Waar moet ik rekening mee houden bij gebrek aan patch?

  • Een aanvaller moet toegang hebben tot een gebruikersaccount om daarvan de rechten naar root te brengen.
  • Het kost heel wat kloktellen om de teller naar 0 te forceren. Om een overflow teweeg te brengen op het gewilde geheugenadres zijn 2^32 systeemcalls nodig. Perception Point testte het op een Intel i7-5500-processor en de pogingen namen 30 minuten in beslag. Op oudere hardware (dus veel embedded systemen) duurt dit veel langer.
  • De exploit is lastig uit te voeren als Supervisor Mode Access Prevention (SMAP), Supervisor Mode Execution Protection (SMEP) of Security-Enhanced Linux (SELinux) zijn geïmplementeerd. Met dit soort middelen wordt de interactie tussen de kernel en userland beperkt. De miljoenen iteraties die nodig zijn voor deze Use After Free-aanval worden door dit soort beveiligingsmiddelen gedwarsboomd.

4. Is Android kwetsbaar?

In principe wel, maar wat dit betreft is er veel goed nieuws. De nu misbruikte feature is geïntroduceerd in kernel 3.8, wat de basis is van Android-toestellen met 4.4 of hoger. Je zou in theorie de bug kunnen misbruiken om het machtigingenmodel te omzeilen om malafide apps uitgebreide machtigingen te geven om diep in te grijpen op het systeem. Maar in de praktijk wordt dat lastig.

Om de bug te kunnen misbruiken moet dus ‘CONFIG_KEYS’ worden ingesteld, maar in de standaardconfiguratie van de Linux-kernel binnen Android is dat niet het geval. Het zal afhangen van de Android-OEM of deze feature is geïmplementeerd.

Een factor die de impact van de bug op Android sterk minimaliseert is beveiligingsuitbreiding SELinux. Dat wordt sinds 4.3 al gebruikt voor het machtigingenmodel van apps en sinds 4.4, de versie die is overgestapt op kernel 3.8, breder ingezet. Vanaf Android 5.0 worden SELinux-policies afgedwongen.

5. Is dit een langetermijnprobleem?

Dat wel. De bug gaat vooral problemen opleveren bij de krachtigere embedded apparaten met een Linux-kernel, bijvoorbeeld industriële machines en betaalsystemen. Bedrijfsservers zijn als het goed is al uitgerust met beveiligingsmiddelen die dit probleem beperken.

Het issue is verder minder nijpend bij bijvoorbeeld handhelds en IoT-apparaten die minder krachtige hardware hebben. De aanval is dan minder aantrekkelijk vanwege de benodigde kloktikken en de daaruit volgende tijdsduur dat een aanvaller zich blootstelt aan ontdekking. Wel is hij geschikt voor ontwikkelaars bij wie dit geen issue is, bijvoorbeeld mensen die lokaal met kwetsbare apparaten aan de slag gaan om ze te rooten.

Bron:   computerworld.nl


Blijven we wakker van blauw licht?

2000633817

Hand opsteken: wie gebruikt er flux of een soortgelijk tooltje om het beeldscherm van de monitor, laptop, tablet of telefoon na zonsondergang wat roder te maken?  De gedachte dat het beter is om het beeld wat roder te maken als de avond is gevallen zit diep.

Op veel andere plekken zien we de stelling dat blauw licht ons wakker houdt terugkomen, maar klopt die gedachte eigenlijk wel? Blijven we inderdaad langer wakker van blauw licht?

Lees het artikel “Blue screen of insomnia” op Tweaker.net voor de conclusie.