Veiliger software door open source
Jaap-Henk Hoepman
Inleiding
Stel, u bent op reis in het buitenland en u voelt zich plotseling onwel. U komt terecht bij iemand die zich als arts uitgeeft en u krijgt van hem het dringende advies de pillen te slikken die uit een of andere bureaulade te voorschijn komen. U vertrouwt het niet helemaal en vraagt om de bijsluiter. Die blijkt er niet te zijn. Men verzekert u dat deze pillen u veel goed zullen doen. Wat doet u?...
Als het om software gaat, blijken we over het algemeen heel erg goed van vertrouwen te zijn: we geloven de producent van de software op zijn woord en gebruiken de software voor de meest kritische toepassingen, zonder maar een moment stil te staan bij de risico's die we lopen en de hoogte van het vertrouwen die we in de producent stellen.
Kan het ook anders? Als we de bovenstaande analogie volgen, wel degelijk. We zouden om de bijsluiter moeten vragen. We zouden moeten eisen te weten hoe de software is samengesteld. Met andere woorden: de source code zou openbaar gemaakt moeten worden.
In de rest van dit artikel gaan we in op de vraag of open source software inderdaad veiliger is dan closed source software.
Openheid: hoe ver moet je gaan?
Het mag in eerste instantie vreemd lijken om de grootst mogelijke openheid na te streven bij de ontwikkeling van software met een kritisch beveiligingsdoel. Immers, hoe minder de aanvaller weet van het systeem, hoe lastiger het is om het systeem aan te vallen. Dat is de reden dat door de eeuwen heen beveiligingsapparatuur in de grootst mogelijke beslotenheid ontwikkeld werd. Denk bijvoorbeeld aan communicatieapparatuur voor het leger of aan de ontwikkeling van de beveiliging van GSM.
Echter, al in 1883 formuleerde Auguste Kerckhoffs het fundamentele principe dat zelfs als een deel van de communicatiemiddelen in handen van de vijand valt, het nog steeds mogelijk moet zijn om veilig te communiceren. In een modernere formulering: de veiligheid moet afhangen van de kwaliteit (en de geheimhouding) van de sleutel en níet van het geheim houden van het gebruikte cryptografische algoritme. Tegenwoordig wordt Kerckhoffs' principe wat algemener geïnterpreteerd, namelijk als de eis dat bij het ontwerp van een beveiligingssysteem ervan uitgegaan moet worden dat de vijand dit ontwerp kent. Zelfs met volledige kennis van het ontwerp van een systeem is het onmogelijk binnen redelijke tijd tegen redelijke kosten in te breken in het systeem.
In Kerckhoffs' dagen was er geen essentieel verschil tussen het ontwerp van een systeem en de implementatie daarvan. Dat is nu wel anders. Ontwerpen van computer programma's zijn veel complexer. De implementatie beslaat duizenden pagina's broncode. Het is onmogelijk om zo'n ontwerp foutloos te implementeren. Alle software bevat wel een aantal bugs. De vraag is dan of Kerckhoffs principe ook moet gelden voor de broncode van software. Met andere woorden: moet veilige software open source zijn, of juist niet? Dit is op dit moment een actueel punt van discussie. We zullen in de rest van dit artikel op de voors en tegens ingaan.
Veiligheid, kwetsbaarheid, en risico
Het is nuttig om onderscheid te maken tussen de begrippen veiligheid (security), kwetsbaarheid (exposure) en risico (risk) van een systeem.
Of een systeem veilig genoeg is wordt bepaald door het risico dat geassocieerd is met het gebruik van dat systeem. Dit risico is een combinatie van de kans op een succesvolle aanval en de schade die zo'n aanval veroorzaakt (en wordt vaak kwalitatief bepaald als het product van beide waarden).
De kwetsbaarheid van een systeem kijkt niet naar de mogelijke schade, maar drukt enkel de kans op een succesvolle aanval uit. Deze kans hangt af van het aantal zwakheden/bugs in het systeem, en hoe ernstig die zijn, maar ook of deze zwakheden bekend zijn bij potentiële aanvallers, hoe moeilijk het is om van zo'n zwakheid gebruik te maken, en of het überhaupt interessant is om het systeem aan te vallen.
(On)Veiligheid, tenslotte, is wat ons betreft een objectieve maat van het aantal zwakheden en de aard en ernst daarvan. Samenvattend: kwetsbaarheid is veiligheid gecombineerd met de waarschijnlijk van een aanval, risico is kwetsbaarheid vermenigvuldigd met geleden schade. Vaak wordt in de literatuur geen duidelijk onderscheid gemaakt tussen (on)veiligheid en kwetsbaarheid. Voor ons is het onderscheid essentiëel: openbaar maken van de broncode van een programma maakt het programma niet onveiliger (de bugs zijn hetzelfde) maar wel kwetsbaarder (de bugs zijn bekend). De vraag is wat de lange termijn gevolgen van het openbaar maaken van de broncode zijn.
Open versus gesloten
Ook is het belangrijk aan te geven wat we precies onder open source software verstaan. Voor ons is dat software waarvan de broncode (en alle relevante documentatie en tools, zoals bijvoorbeeld compilers) beschikbaar is voor de gebruiker voor inspectie, verbetering, en gebruik. Optioneel mogen verbeteringen aan de software (patches) vrijelijk gedistribueerd worden (maar noodzakelijk is dat niet).
We maken geen onderscheid tussen ontwikkelmethoden voor software, of prijsstelling (shareware vs freeware), of specifieke licenties (GNU Public Licencse (GPL)). Ook zullen we verder niet ingaan op de economische motieven voor of tegen open source software.
Veel informatie over open source is te vinden via de website van het programma Open Standaarden en Open Source Software voor de overheid
Geslotenheid, immers: informatie is (over)macht...
Er zijn een aantal argumenten die pleiten voor het geheim houden van de broncode van een programma.
Het belangrijkste argument is wel dat door het openbaar maken van de source een aanvaller eenvoudig op zoek kan gaan naar de onafwendbaar aanwezige bugs (zoals buffer overflows) in het programma, en zo de beveiligingsmaatregelen kan omzeilen. Daar waar in het ontwerp aanwezige fouten nog door grondige reviews of door middel van tools gevonden en hersteld kunnen worden, is dit voor de sourcecode van software in de nabije toekomst zeker niet het geval.
Bovendien is de aanvaller onevenredig in het voordeel: daar waar de aanvaller maar één zwakke plek hoeft te vinden voor een succesvolle aanval, moet de verdediger alle zwakke plekken herstellen om zo'n aanval te voorkomen.
Ook al is de broncode openbaar, dan geeft dat nog geen garantie dat de corresponderende executable geen bugs of back doors bevat. Lang niet altijd heeft de gebruikers de beschikking over alle tools of libraries om de software zelf te compileren, en zal dan alsnog moeten vertrouwen op een derde partij. Bovendien kan de compiler zelf ook nog bugs bevatten of met opzet backdoors meecompileren. Zo zou bijvoorbeeld de standaard library, die veelal wordt meegelinkt en die standaard routines bevat voor bijvoorbeeld in- en uitvoer, met een trojaans paard vervuild kunnen zijn.
Het openbaar maken van de source garandeert ook helemaal niet dat voldoende gekwalificeerde mensen de source code controleren. Er zijn genoeg open source projecten te vinden die na een korte periode van veel programmeeractiviteit weer in de vergetelheid zijn beland.
Tenslotte geldt dat het ook relatief eenvoudig is om back doors toe te voegen aan een niet strikt geleid open source software project. Zo werd zelfs in de Linux kernel in November 2003 een backdoor ontdekt. Het ging hierbij op het eerste gezicht om een onschadelijke controle op de invoer parameters van een systeem functie, die echter in werkelijkheid er voor zorgde dat als de systeem functie met een bepaalde (onwaarschijnlijke) combinatie van inputs zou worden aangeroepen, de aanroeper root privileges zou krijgen. De backdoor werd ontdekt door een standaard integreteitscheck tijdens de synchronisatie van twee linux kernel code repositories.
Maar hoeveel macht is dat eigenlijk...
Laten we de bovengenoemde argumenten tegen open source (of voor closed source, zoals u wilt) eens nader bekijken.
Het laatste argument geld natuurlijk net zo goed voor closed source software. Zelfs pakketten als Microsoft Office bevatten zogenaamde "easter eggs" waarvan lang niet altijd duidelijk is of het hogere management daarvan op de hoogte was. Sterker nog, als de source openbaar is kunnen software projecten niet meer zo eenvoudig wegkomen met slecht project management en kwaliteitscontrole.
Wat betreft het eerste argument: het blijkt uitermate lastig te zijn de source code van software lang geheim te houden. Sofware van stemmachines (bij toeval gevonden op een ftp site), en recentelijk zelfs van Windows NT, zijn openbaar geworden. Het geclaimde voordeel voor de verdediger is dus slechts van korte duur.
Zelfs zonder de beschikking te hebben over de source kunnen aanvallers vrij eenvoudig, door middel van bijvoorbeeld debuggers en disassemblers, bugs en zwakheden in software vinden. De verdedigers daarentegen kunnen, zonder beschikking te hebben over de hele source, niets doen om deze bugs te verhelpen. Alleen de producent van de closed source software kan dergelijke patches of updates distribueren. Dat kan soms lang duren, en in het geval van al wat oudere (zgn legacy) software gebeurt het al helemaal niet. Voor legacy software geldt trouwens dat alleen al voor de continuïteit van de bedrijfsvoering de source in bezit van het bedrijf zou moeten zijn: stel je voor dat de oorspronkelijke leverancier niet meer bestaat en de source voor altijd verloren is geraakt...
We zien dat het gesloten houden van de source de verdediger veel meer schaadt dan de aanvaller: de aanvaller vindt de zwakheden toch wel met redelijk gemak, terwijl de verdediger zonder enige vorm van verweer hulpeloos moet toezien.
Informatie is macht: Openheid!
Het belangrijkste argument vóór open source is wel dat het gebruikers in staat stelt om zelf de veiligheid van de software te bepalen (of om andere partijen hiervoor in te huren).
Als er een bug gevonden is, kan de gebruiker die zelf herstellen. Als de patch vervolgens via bijvoorbeeld een website gedistribueerd wordt, kunnen alle andere gebruikers deze patch gebruiken om hun eigen systemen ook te herstellen. Deze gebruikers zelf vinden misschien weer andere bugs: het netwerk effect in optima forma. Of in de woorden van Linus Torvalds: "Given enough eyeballs, bugs are shallow". Wel moet er natuurlijk voor gezorgd worden dat niet juist via deze patches allerlei bugs of backdoors geïntroduceerd worden.
Mocht een gebruiker de bug niet zelf kunnen herstellen, dan stelt het beschikbaar zijn van de source hem in ieder geval in staat om efficiënter en duidelijker over de bug te communiceren: gebruiker en ontwikkelaar hebben de dezelfde "frame of reference", nl. de source code. Ook dit zorgt ervoor dat bugs sneller opgelost kunnen worden.
Ook zijn er tools die, gegeven de source code, extra beveiligingsmaatregelen aan het programma toe kunnen voegen. Zo zijn er utilities (zoals StackGuard) die run-time checks tegen bijvoorbeeld buffer overflows implementeren. Zonder de source code zijn dergelijke utilities onbruikbaar.
Als de source code beschikbaar is, kan de gebruiker ook beslissen om bepaalde delen van de software niet te gebruiken en daarom ook niet te compileren. Dit verlaagt de complexiteit van het systeem, wat weer de veiligheid verhoogt.
Conclusies
Ondanks de bezwaren die over het algemeen worden opgeworpen, zien we dat het openbaar maken van de source de veiligheid van de software wel degelijk ten goede komt. Ten eerste omdat gebruikers de software zelf op zijn merities kunnen beoordelen. Ten tweede omdat gebruikers zelf fouten in de software kunnen herstellen, zonder hiervoor afhankelijk te zijn van de producent.
Dit is zeker niet voor iedere gebruiker weg gelegd. De benodigde expertise is echter zeker beschikbaar bij universiteiten en de open source community, en bij grotere (software) bedrijven. Met het meer beschikbaar komen van open source kan deze expertise benut en uitgebreid worden, en zullen er allerlei vormen van veiligheids evaluatie diensten aangeboden worden, ter verbetering van de veiligheid van software voor alle gebruikers.
Dr. Jaap-Henk Hoepman is senior onderzoeker security en cryptografie aan de Radboud Universiteit Nijmegen.
Dit artikel is verschenen in Informatiebeveiliging, 2005.
Last Version - e1e3326.
(Note: changeover from CVS to dotless svn version numbers on Jan 19, 2008, and changeover to GIT versioning on May 30, 2013.)
Maintained by Jaap-Henk Hoepman
Email: jhh@cs.ru.nl