De hacker die claimt computers te kunnen hacken via bugs in Intel-processor is een voorbeeld van de huidige trend in het onthullen van beveiligingsgaten. In de Linux-wereld woedt er nu een discussie over het stilhouden van details over bugs in de kernel.
Beveiligingsonderzoeker Kris Kaspersky, niet gerelateerd aan het gelijknamige Russische antivirusbedrijf, zegt computers op afstand te kunnen aanvallen door gebruik te maken van bugs (errata) in Intel-processoren. Het zou gaan om bekende, gedetailleerd omschreven fouten. Kaspersky doet deze onthulling zonder vooraf contact met Intel te hebben gehad. Die chipproducent wacht nu het onderzoek, met details, van de hacker af.
Het onthullen van beveiligingsgaten – soms met al details over het gat – is een trend in beveiligingsland. Al jaren woedt er een felle discussie over het wel of juist niet openbaar maken van gaten en exploits daarvoor. Crackers zouden namelijk die informatie gebruiken en daarmee patches van leveranciers vóór zijn, of weer kunnen omzeilen. Onder meer Microsoft pleit voor meer terughoudendheid door ontdekkers van gaten, terwijl beveiligingsexperts als Bruce Schneier juist stelt dat volledige onthulling van bugs leidt tot een kortere periode van kwetsbaarheid.
Bugs in Linux
In de opensource-gemeenschap laait nu net een nieuwe discussie op. Het gaat om details over bugs in de kernel van besturingssysteem Linux. Door het fundamentele niveau van de kernel zijn fouten daarin bijna altijd ernstig te noemen. Terwijl patches vrij snel beschikbaar kunnen zijn, zeker voor opensource-software, worden die niet altijd meteen opgenomen in alle Linux-distributies. Zo is er een vastgelegd update-ritme voor zakelijke Linux-uitvoeringen.
Linux-schepper Linus Torvalds staat opvallend genoeg aan de kant van de voorstanders van geheimhouding. Hij heeft nog altijd flinke invloed op en zeggenschap over de ontwikkeling van de Linux-kernel. Er is nu dus ophef over de discrepantie tussen de officiële openheid van Linux, ook met betrekking tot bugs, en de praktijk.
Die praktijk blijkt dus uitzonderingen te bevatten. Zo is Torvalds er zelfs voor om details van bugs te beperken in de comments van fixes. "Als het niet al een zeer publieke kwestie is, wil ik niet dat het door een eenvoudig 'git log + grep' is te vinden", aldus de oorspronkelijke maker van Linux.
In kleine kring is bekend dat er een klein aantal bugs in de intel processoren zitten die inderdaad kunnen leiden tot aanvallen van buitenaf. Voor het gemak word daar het probleem neergelegd. Maar een potentiele hacker moet dan wel eerst toegang tot de pc krijgen en dan zijn exploit voor de “errata” kunnen runnen.
Vele malen gemakkelijker is het, en dan maar meteen een bug blootleggend, gebruik te maken van root kits. Met behulp van atsiv (inmiddels ook al verouderd) loop je redelijk gemakkelijk door alle beveiliging heen. het gebruik van atsiv word door virusscanners wel gevonden, maar die beveiliging is vrij simpel te omzeilen.
De vraagstelling eindigt met: maken we security issues bekend of niet?
Ieder heeft daar wel een mening over, en ik dus ook.
Ja, maak alle beveiligings issues bekend. Daarmee geef je hackers op een korte termijn veel informatie, maar na een kleine week is dat opgelost en werkt het niet meer.
Nee, maak beveiligings issues niet bekend. Probleem is dan dat veel mensen onbewust niet de juiste maatregelen treffen.
Mijn mening is dat er een gesloten circuit moet komen van beveiligings experts die besloten de informatie krijgen en daarmee aan de slag gaan. Zodra er dan een oplossing is, is er ruimschoots tijd om juiste maatregelen te treffen.
Tja, een eeuwigdurende discussie en beide kampen hebben gelijk. De vendor heeft zonder publicatie minder behoefte om snel patches te leveren maar het ongenuanceerd publiceren vergroot het risico op misbruik van een probleem. Dat geeft maar weer aan dat we een toezichthouder moeten hebben waar de meldingen worden gedaan (de melder in het spotlight met een cijfer en een bonus voor de ontdekking) en op straffe van boetes toeziet op snelle oplossing. Ik denk dat Neelie die kar wel wil trekken. En het probleem van wie er dan bij open source verantwoordelijk is? Dat is simpel, het bedrijf dat verdient bij keuze van de software moet betalen – en bij open source is dat… de klant.
Helaas is het zo dat alle apparatuur beveiligingslekken heeft. Of het nu de PC, het netwerk, of de beveiligingsfuncties binnen het netwerk betreft. Het is niet het bestaan van het lek dat belangrijk is maar de hoogte van de drempel (in relatie tot de beoogde buit) om hier gebruik van te maken. Het nieuwe hier zou zijn dat er malware ontwikkelt is (of kan worden) die besturingssysteem onafhankelijk is en de beveiligingsproblematiek verplaatst naar de ontwikkelaars van de BIOS en de chipfabrikanten. (Overigens niet geheel nieuw als we de recente problematiek rond de in China “gekloonde” Cisco switches herinneren, hier is bewust een beveiligingslek in de firmware ingebouwd.)Met de toenemende afhankelijkheid van IT is beveiliging een primaire taak geworden voor alle bedrijven en dat wordt helaas nogal eens over het hoofd gezien.
Het bekende “onder de pet houden” is geen oplossing. Ten eerste zijn er wettelijke beperkingen, Amerikaanse bedrijven hebben bijvoorbeeld de plicht de hun bekende problemen te publiceren. (Ook de Nederlandse rechter heeft recent in het geval van de OV chipkaart problemen de zijde van de onderzoekers gekozen en de leverancier die publicatie van de hack techniek wilde voorkomen in het ongelijk gesteld.)
Daarnaast is het op dit ogenblik al zo dat de research firmas de leveranciers van s/w en hardware een beperkte tijd geven om te reageren voordat ze de problematiek openbaar maken. Zo heeft ook Kaspersky Intel en de BIOS leveranciers de gelegenheid gegeven de bekende bugs te verbeteren. Dat de hieraan verbonden kosten de leveranciers terughoudend maken verbeteringen door te voeren is ook een feit, publicatie is dan een goede stimulans. Intel zou niet blij zijn met het imago dat Motorola chips beter zijn. (hetgeen natuurlijk niet zo is, elke chip heeft zijn problemen het is een kwestie van focus of ze wel of niet ontdekt worden.)
Ook zou ik niet zo goed weten wie binnen dat “gesloten circuit van beveiligingsexperts” plaats moeten nemen. Wie zou buitengesloten moeten (en kunnen) worden. Zou Frankrijk accepteren dat de US beveiligingsproblematiek voor zich zelf houdt? Zou de Rabobank voor zijn beveiliging afhankelijk willen zijn van de ING? Een raffinaderij afhankelijk van de beveiligingsexperts van een bank? Op het gebied van terorisme bestaat deze uitwisseling ook tussen veiligheidsdiensten, maar uiteraard wel een clubje van vriendjes met de nodige wederzijdse skepsis.
Een besloten clubje leidt tot veel meer problemen dan mee te blijven rennen in deze rat race van onderzoek, publicaties, en betaalde bescherming. Een economische cyclus die alleen te doorbreken is door de perfect beveiligde oplossing te ontwikkelen, helaas is dit een beveiligingsdoel dat we nooit bereiken.
Onmiddelijke onthulling van alle details van een nieuwe kwetsbaarheid is niet goed voor de algemene veiligheid. Zelfs onthulling achteraf via documentatie bij de patch is niet aan te raden. Hackers hebben soms slechts uren nodig om een uitbuiting ervan te maken, maak het ze niet te gemakkelijk.
Onthulling is wel het ultieme machtsmiddel van de ontdekker van de kwetsbaarheid. Als de softwareproducent geen acceptabele oplossing leveren tegen de kwetsbaarheid in een redelijke tijd, kan de ontdekker overgaan tot onthulling. Zo wordt de softwareproducent gehouden aan een eerlijke marktafweging. Dit is essentieel voor het veilig houden van de software op de markt. Kennelijk grijpen ontdekkers nu echter vaker en sneller naar dit machtsmiddel. Is de pendule te ver doorgezwaaid?
Het zou daarom helpen als er goede richtlijnen afgesproken werden over het proces naar zo’n onthulling toe. Dan kan de markt de ontdekker eventueel aanspreken op zijn verantwoordelijkheid…
Het is vanuit verschillende perspectieven noodzakelijke dat kwetsbaarheden gemeld worden door zowel een leverancier als wel de ’test / hacker’ gemeenschap.
Vanuit verschillende wetgevingen is de ondernemer (eind gebruiker) verantwoordelijk voor goed ondernemerschap en zijn eindproduct. Als bank, telco of energie leverancier heb je zelfs een leveringsplicht, dan dienen bepaalde diensten beschikbaar te blijven. Dus bij het inzetten van middelen zou ik dus als ondernemer (risico manager / security specialist) willen weten wat het risico is (bij inzet van een product) en waar de zwakheden (beperkingen) zitten. Dit alleen al om indien nodig tegenmaatregelen te introduceren.
Juridisch gezien zal het heel raar zijn dat bedreigingen dan ook gedeeltelijk / of bij een beperkte groep bekend zouden zijn. Zit ik niet in de groep, dan weet ik niets en kan dus ook het risico niet beheersen. Terwijl ik wel aansprakelijk ben. Verder zal ik de schade ontstaan aan het gebruik van een ondeugdelijk apparaat (waarvan mij de beperkingen niet gemeld zijn) ook willen verhalen.
Wat m.i. nog meer pleit voor het bekend maken is dat er al jaren bij leveranciers (en andere kleine sub-groep) bekende bug’s zijn die maar niet opgelost worden. Het zelf regulerende karakter van het eerst bekend maken bij de leverancier en deze dan tijd geven om orde op zaken te stellen werkt dus niet.
Bijkomstig bij het gedrag van leveranciers is dat deze vaak (TCO technisch) de kwaliteit laag houden en het testen van producten minimaal uitvoeren. Ik als eindgebruiker zit na het kopen van het product met de zooi. Had ik geweten van de beperkingen (fouten) dan had ik mijn keuze wellicht anders gemaakt.
Een hacker of vreemde mogendheid ‘weet’ de bedreigingen toch wel te vinden en te gebruiken. Het niet bekend maken is een schijn veiligheid die nadelig werkt voor de eindgebruiker. Deze dom houden is iets wat veel organisaties willen maar is altijd contraproductief en zeker niet veilig.