Open source niet veiliger dan reguliere software

Veel voorstanders van de open software vinden dat fouten in deze software transparanter en beter traceerbaar zijn dan bij gesloten software. Doordat een gebruiker bij open software beschikt over de broncode van het programma, is hij in staat om dergelijke fouten zelf op te sporen. Volgens hen is dit, vanuit beveiligingsoogpunt gezien, zelfs een van de grote voordelen van deze software. In theorie hebben zij gelijk, maar de praktijk blijkt vaak anders te zijn. Om verschillende redenen wordt open software vaak op dezelfde wijze geïnstalleerd als gesloten software waardoor het beveiligingsvoordeel teniet wordt gedaan. In sommige gevallen worden zelfs extra beveiligingsrisico’s geïntroduceerd. De conclusie is echter wel dat open source-software in ieder geval de (theoretische) mogelijkheid biedt tot het uitvoeren van een code-inspectie, en dat deze software bij een juiste inzet en gebruik wel degelijk voordelen biedt. Open source-software wordt in het algemeen ontwikkeld door een aantal vrijwilligers dat in een losse structuur met elkaar samenwerkt. De distributie geschiedt veelal via Internet en in de vorm van een broncode. Dit laatste betekent dat iedereen die weet waar hij deze software op Internet kan vinden, de broncode kan inzien en zelf daarvan een programma kan of moet bouwen op zijn computer. Een bekend voorbeeld van dergelijke software is Linux, dat volledig via Internet beschikbaar is in broncode. Bedrijven als Red Hat en Suse distribueren deze code ’alleen maar’ in een vorm die voor veel mensen hanteerbaar is. Overigens voegen zij vaak ook functionaliteit aan Linux toe en geven deze dan ’terug’ aan de open source-gemeenschap. Deze beschrijving van het open model is verre van compleet, want binnen deze gemeenschap zijn verschillende stromingen actief die elkaar met bijna religieus enthousiasme bestrijden. Daar tegenover staat het gesloten model. Dit is de klassieke manier van software-ontwikkeling en -distributie waarbij de software uitsluitend in uitvoerbare vorm wordt aangeboden. Met andere woorden, deze software kan iemand direct installeren en uitvoeren zonder deze zelf te bouwen. De leverancier verstrekt echter niet de broncode, die wordt als een goed geheim bewaard in het bedrijf. De klant betaalt voor deze software een gebruikerslicentie, een recht om de software te mogen gebruiken. (Merkwaardig is dat ondanks deze licentiebetaling de software veelal eigendom blijft van de fabrikant.) Een bekend voorbeeld van een fabrikant van reguliere software is Microsoft, die een breed scala aan producten levert voor allerlei toepassingen en platformen. Daarnaast zijn er allerlei andere leveranciers die producten leveren. Sommige daarvan zijn zelfs specifieke beveiligingsproducten zoals firewalls en intrusion detection-systemen. Crashen Software bevat fouten, dat weet iedereen. Onder de meest uiteenlopende omstandigheden crashen programma’s, al dan niet inclusief de rest van de computer. Ontwikkelaars zijn mensen en maken dus fouten bij het ontwikkelen van programma’s. Door verkeerde aannames reageren programma’s onvoorspelbaar op onverwachte invoer of omstandigheden en crashen. Daarnaast is er een constante druk om nieuwe versies van een programma uit te brengen, een druk die vaak leidt tot het niet volledig kunnen testen van een programma, met alle gevolgen van dien. Ook de complexiteit van een programma kan er toe leiden dat het onmogelijk is om alle variaties te testen, simpelweg omdat deze niet allemaal kunnen worden gesimuleerd. Verder zal de krapte op de arbeidsmarkt een steeds grotere rol spelen. Ervaren programmeurs worden goud waard, en het blijft moeilijk de juiste kennis en ervaring bij elkaar te krijgen voor het uitvoeren van een groot of klein programmeerproject. Overigens doen programmeurs hun werk goed en de meeste software is verre van slecht. In de laatste jaren is er een aantal methoden ontwikkeld om de kwaliteit van de software te verbeteren en te controleren. Maar ondanks alles blijven er fouten in software zitten. In het algemeen zijn deze fouten ’alleen maar’ lastig. Ze laten programma’s of systemen crashen en verstoren zo het dagelijkse werk. Deze problemen, hoe lastig ook, blijven beperkt tot de gebruiker van het systeem of de software. Dit verhaal krijgt echter een andere wending als deze fouten ook leiden tot gaten in de beveiliging van systemen en, in ruimere zin, informatie. Iedereen die regelmatig de beveiligingsmeldingen op Internet bijhoudt zal zien dat er met de regelmaat van de klok nieuwe beveiligingsproblemen worden ontdekt in allerlei software, zowel open als gesloten software. De website www.securityfocus.com houdt hier statistieken over bij. Fouten In het overzicht van het jaar 2000 blijken er in allerlei platformen fouten te zitten die leiden tot beveiligingsrisico’s. In zijn statistieken houdt Security Focus alleen de fouten bij die leiden tot beveiligingsrisico’s, alle andere fouten worden niet meegeteld. Hoewel statistieken niet altijd een betrouwbaar beeld geven, geven ze wel een aardige indruk van de huidige situatie (zie tabel). Uit het overzicht van Security Focus voor 2000 blijkt dat Windows NT/2000 bovenaan staat, Linux staat op een goede tweede plaats. Niet alle fouten van de Linux-distributies kunnen bij elkaar worden opgeteld, vaak komen dezelfde fouten in verschillende distributies voor. Naast een overzicht per jaar, houdt Security Focus ook bij hoe deze trend zich heeft ontwikkeld over de afgelopen jaren. Hieruit blijkt dat er steeds meer beveiligingsfouten in software worden ontdekt, zowel in de open als reguliere software. Uit de cijfers blijkt dat er relatief net zoveel beveiligingsfouten in open als gesloten software zitten, ondanks het voordeel van open source-software met zijn distributie in broncodevorm. Dit vindt zijn oorzaak in het feit dat de meeste van deze projecten zoals Linux in korte tijd van dezelfde complexiteit zijn geworden als reguliere software. Het aantal coderegels voor Windows 2000 loopt in de miljoenen. Als men een Linux-systeem opbouwt met dezelfde functionaliteit (dus inclusief grafische omgeving en dergelijke) dan komt men al snel op een vergelijkbare hoeveelheid coderegels. Als men aanneemt dat de programmeurs die reguliere en open software maken even goed zijn (niet ondenkbaar omdat veel professionele programmeurs in hun vrije tijd aan open source-projecten meewerken) dan zullen beide omgevingen ongeveer evenveel fouten bevatten per tienduizend coderegels. Superprogrammeur Er zijn diverse redenen te noemen waarom systeemfouten in open software niet eerder worden ontdekt dan in gesloten software. Ten eerste moeten de gebruikers van open software de kennis en ervaring hebben om een code-inspectie te kunnen uitvoeren. Dit betekent in de praktijk dat mensen met programmeerervaring beschikbaar moeten zijn om de broncode van het product door te lezen en te doorgronden zodat zij in een tweede slag de fouten eruit kunnen halen. De kennis die hiervoor nodig is kan heel specifiek zijn. Zo is Linux een multi-user-besturingssysteem dat op een grote variatie aan hardware kan werken (van een Intel-processor tot een IBM-mainframe). Voor een goede review en evaluatie is minstens zoveel en diepgaande kennis nodig als die van de programmeur die het heeft ontwikkeld. Bovendien zal degene die de code-review uitvoert, dit moeten doen vanuit een beveiligingsperspectief. Ook dit vergt specifieke kennis en een gezonde dosis paranoia. Bij veel onderdelen van de programmatuur zal de reviewer zich moeten afvragen ’wat als?’, om de risico’s van de code te kunnen inschatten. Dit betekent dat de reviewer zich de aannames van de programmeur bij het ontwikkelen van de code, zal moeten kunnen eigen maken. Samenvattend komt het er op neer dat een reviewer een soort ’superprogrammeur’ dient te zijn om een goede review te kunnen doen. Deze mensen zijn zo schaars dat zij eerder worden ingezet bij de ontwikkeling van eigen producten in plaats van het reviewen van bijvoorbeeld open sourcesoftware, zeker als die net zo groot en complex is als de programmeerprojecten die zij moeten uitvoeren. Ten tweede moet een reviewer ook de tijd hebben om de review te kunnen uitvoeren. Het beslag dat op zijn kostbare tijd wordt gelegd, kan sterk oplopen. Zo sterk dat in sommige gevallen bijna net zoveel tijd nodig is voor de review als voor het eigenlijke programmeren van de software. Iedereen die wel eens zelf heeft geprogrammeerd, weet uit eigen ervaring dat het niet eenvoudig is om de software van een andere programmeur te begrijpen. Iedere programmeur heeft een eigen stijl en eigen oplossingen voor problemen. Een reviewer van de code moet naast de functionaliteit van de code zelf ook deze stijl doorgronden. Pas dan is hij in staat om de code op de juiste manier te bekijken. Een andere factor die de beschikbare tijd nadelig beïnvloedt is de snelheid waarmee sommige van deze open producten nieuwe versies en patches uitbrengen. Is een specifieke versie net volledig aan een review onderworpen, dan is er al weer een nieuwe versie beschikbaar. Wat dat betreft onderscheiden beide soorten software zich niet van elkaar. Achterdeuren Deze aspecten in ogenschouw genomen, lijkt de situatie voor open software somber. Laten we echter niet vergeten dat dit model in ieder geval wel de (theoretische) mogelijkheid biedt om een review uit te voeren. Voor daadwerkelijk beveiligingskritische systemen kan, afhankelijk van de prioriteiten en belangen, inderdaad een review worden uitgevoerd. Deze mogelijkheid biedt de reguliere software in het algemeen niet. De software is een black box, waarbij de gebruikers de fabrikant zullen moeten vertrouwen. Natuurlijk kan een fabrikant van dergelijke software een goede (potentiële) klant wel de mogelijkheid bieden om op locatie een inspectie te doen van de broncode, maar ook in dat geval zal altijd twijfel blijven bestaan of de code die geïnspecteerd is, ook daadwerkelijk de broncode is die voor het bouwen van het uitvoerbare programma is gebruikt. Verder blijken de geruchten over achterdeuren in allerlei commerciële producten zeer hardnekkig en zijn deze voor sommige gebruikers al reden genoeg om geen commerciële software uit bepaalde landen te gebruiken. Daarnaast baseren gebruikers zich in deze gevallen vaak op het argument dat een fabrikant van een gesloten softwareproduct in het geval van een beveiligingsprobleem sneller reageert met patches en in het geval van echte calamiteiten ook aanspreekbaar is voor eventuele schade. Ook dat blijkt in de praktijk tegen te vallen. De licentie die bij veel van dit soort software zit, vrijwaart de fabrikant van vrijwel alle aansprakelijkheid, ook in het geval van beveiligingsproblemen. Het is een zeer leerzame oefening om een dergelijk licentie door te lezen. Onveiliger Samenvattend kan worden geconcludeerd dat in echte beveiligingskritische situaties open software wel degelijk beveiligingsvoordelen biedt. In de alledaagse praktijk valt dit beveiligingsvoordeel echter weg door een gebrek aan kennis en tijd voor het uitvoeren van een code-review. Om ook in deze alledaagse praktijk goed en veilig gebruik te kunnen maken van deze software dient een aantal zaken goed in het oog te worden gehouden. De open software moet van een betrouwbare bron worden betrokken. Er zijn gevallen bekend waarbij een kwaadwillende programmeur achterdeuren in een bekend open product had ingebouwd en deze vervolgens heeft aangeboden op Internet. De gevolgen laten zich raden. In dit geval leidt het gebruik van de verkeerde (bron voor) open software juist tot een onveiligere situatie, wellicht zelfs met een vals gevoel van veiligheid. Het is het beste de broncode direct van de auteur(s) te betrekken. Houd er hierbij wel rekening mee dat het meeleveren van checksums geen enkele garantie biedt voor de integriteit van de code: iemand die de code kan wijzigen kan dit uiteraard ook doen met de checksums. Houd mailinglists, websites of nieuwsgroepen bij die gerelateerd zijn aan het product. Hier is niet alleen een schat aan informatie en hulp te vinden, ook beveiligingsproblemen met het product worden hier vaak als eerste vermeld, veelal inclusief de bijbehorende oplossing. Tevens vindt de gebruiker hier aankondigingen van nieuwe versies en kunnen zij nieuwe features in het product aanvragen. Net als bij beveiliging geldt ook hier dat degene met de meeste kennis voorop loopt. Ir. Arthur Donkers is directeur van Le Reseau netwerksystemen BV te Groningen en Amsterdam (arthur@reseau.nl; http://www.reseau.nl).