Softwareprogrammeurs maken teveel fouten. Standaardfouten in de C++-methode liggen aan de wortel van de meeste beveiligingsproblemen.
Ontwikkelaars zijn zich niet bewust van de beveiligingsproblemen door fouten in de software. “Zij worden daar in eerste instantie niet op afgerekend”, zegt hoogleraar softwarebeveiliging Erik Poll van de Radbouduniversiteit in Nijmegen. “Soms wordt bepaalde apparatuur pas een paar jaar na het ontwikkelen aan internet gehangen. Pas dan blijkt er opeens een probleem te zijn.”
Volgens professor Poll schort het aan onderwijs op dit vlak. In programmeeropleidingen zou beveiliging zelfs een ondergeschikte rol spelen. Hij wijt dat onder meer aan de talen waarin geprogrammeerd wordt. ““n C en C++ zullen altijd fouten gemaakt blijven worden, maar er zouden wel meer fouten dan nu voorkomen kunnen worden.” De makkelijkste manier om de huidige beveiligingsproblemen op te lossen, is om allemaal in Java en C# te gaan programmeren. “Mensen zullen zeggen dat deze twee talen twee keer zo langzaam zijn, maar als je elke maand patches moet uitbrengen, of oude codes moet gaan reviewen, kost dat ook veel tijd”, aldus Poll.
Eens of oneens?
Ben je het eens met professor Poll? Zijn programmeurs in C en C++ slordig en is dit een grote oorzaak van beveiligingsproblemen? We horen graag je mening op computable.lezers@bp.vnu.com!
Het is wel wat naïef om te denken dat alle beveiligingsproblemen zijn opgelost wanneer je C# of Java gaat gebruiken. Maar inderdaad: beide platforms bieden veel meer ondersteuning op het gebied van beveiliging. Als je C++ niet hoeft te gebruiken, dan vooral niet doen. Door Bjarne Stroustrup’s starre opstelling is het inmiddels een stoffig taaltje, waar niet veel ontwikkeling meer in zit.
Overigens: C# is niet twee maal zo langzaam als C++. Het scheelt in veel gevallen slechts enkele procenten.
Hoe vaak worden deze misplaatste vergelijkingen niet gemaakt? Mijn vader (overleden 1977) wist niets van computers, maar wel dat software het grootste probleem was.
Door gebruik te maken van andere programmeertalen, platformen, architecturen maken we problemen niet eenvoudiger. We verschuiven de eigenlijke problematiek over een denkbeeldige lijn, die techniek, computertaalkracht, eenvoud en menselijk falen behelst.
Het op te lossen probleem blijft gelijk. Een vergelijking tussen C, C++ en Java is alleen zinnig als er iets te vergelijken valt! De taal C is een programmeertaal terwijl Java een ontwikkelplatform is.
Het is hetzelfde om een boekhouder achter zijn geschreven boekhouding te vergelijken met een niet-boekhouder achter een pc met het beste boekhoudprogramma. Je moet wel weten wat je aan het doen bent. En gek misschien, maar ik vertrouw meer op die papieren boekhouder.
De uitspraak “Mensen zullen zeggen dat deze twee talen twee keer zo langzaam zijn, maar als je elke maand patches moet uitbrengen, of oude codes moet gaan reviewen, kost dat ook veel tijd” is een beetje krom. Er zijn inderdaad mensen die zeggen dat Java en C# trager zijn dan b.v. C of C++, maar daarmee wordt gedoeld op de snelheid van de software. Elke maand patches uit moeten brengen en reviewen hebben invloed op de snelheid van het project, niet op de snelheid waarmee software wordt uitgevoerd.
De kans op met name geheugenfouten door b.v. het toepassen van dynamische geheugenallocatie, is in het geval van C of C++ groter dan bij Java of .NET. Ik denk echter niet dat C of C++ programmeurs slordiger zijn dan programmeurs die in omgevingen werken met garbage collectors en dergelijke.
Ook denk ik niet dat het programmeren in Java of C# de oplossing is. In de embedded wereld zullen, gezien de platformeigenschappen, Java en C# nog niet altijd kunnen worden toegepast. Niet alleen vanwege de snelheid en het geheugengebruik, maar ook omdat sommige systemen hard-real-time gedrag vereisen. De garbage collector kan daarbij wel eens een probleem vormen, al kun je die ook uitschakelen.
Persoonlijk denk ik dat C en C++ nog prima kunnen worden gebruikt. Veel fouten kun je niet alleen voorkomen door procesmatige aspecten als reviewen en gestructureerd testen, maar je zou ook kunnen denken aan statische en dynamische codecontrole, ofwel vergroting van de inzet van controlerende tools.
Het gebruik van de Standard Template Library kan ook al veel problemen ivm geheugenallocaties oplossen,
en het versnelt het programmeren aanzienlijk.
Eens en oneens, ben ik met de stelling dat programmeurs in C en C++ slordig zijn en daardoor het security probleem veroorzaken. Ik ben van mening dat de keuze voor de programmeertaal het probleem niet veroorzaakt noch voorkomt.
Mijn inziens moeten we de oorzaak van het probleem primair zoeken in het feit dat kwaadwillenden sindskort steeds vaker over de applicatie laag inbreken (volgens Gartner zelfs meer dan 70% van de hacks vinden plaats op deze laag) en dat hierdoor de programmeurs zich voor het feit geplaatst zien dat zij in het verleden security kwetsbaarheden hebben verwaarloosd. Slordigheid zou ik hen niet direct willen verwijten aangezien het security aspect nooit hoog op de prioriteitenlijst gestaan heeft in tegenstelling tot functionaliteit, performance etc.
Gedwongen door ontwikkelingen in de markt lijkt het alsof er nu mondjesmaat bewustzijn begint te ontstaan bij applicatie ontwikkelende bedrijven. Dit gaat echter veel te langzaam en als we niet sneller gaan acteren blijven we achter deze problematiek aan lopen. Ik pleit ervoor dat in het requirements traject (specificaties) een prominente plaats wordt gereserveerd voor het security aspect. Hierdoor zullen programmeurs en testers meer tijd krijgen om aan dit aspect tijd te besteden. Daarnaast sluit ik me geheel aan bij de opmerking van hoogleraar Poll dat security meer aandacht verdient tijdens de opleiding van de nieuwe generatie programmeurs.
Ten aanzien van de oplossing van het probleem denk ik niet dat we deze zullen vinden in de keuze voor een programmeertaal. Ik denk dat de oplossing meer gezocht moet worden in de combinatie van bewustzijn/kennis mbt software security en technologie die de programmeurs/testers in staat stelt om de code en applicaties op een effectieve en efficiente manier te valideren op het security aspect. Al jaren zijn er tools waarmee je zo genaamde applicatie penetratie testen automatisch kon runnen maar het probleem daarmee was dat deze de applicatie als een black box beschouwden met als gevolg dat de resultaten slechts aangaven dat er een kwetsbaarheid was maar geen enkele specifieke aanwijzing waar het probleem zat. De andere methode was de handmatige code review met als grote nadelen het kostenaspect maar ook de complexiteit en daarmee de effectiviteit van de review.
Fortify Software (Palo Alto, California) heeft de problematiek een paar jaar geleden onderkend en heeft technologie ontwikkeld om deze security vulnerabilities automatisch te detecteren middels Source Code Analyse (white box) waardoor de effeciency en effectiviteit enorm zijn toegenomen. De tool vertelt immers precies in welke coderegel het probleem zit en runt de test in een fractie van de handmatge tijd. Door deze technologie krijgen developers eindelijk een tool in handen waardoor het security aspect (naast alle andere aspecten) voor hen een beheersbaar probleem wordt.
In de VS hebben enkele zeer grote en bekende bedrijven reeds deze technologie geadopteerd (Oracle, Bank of America, Wells Fargo, Cingular). Aangezien Fortify Software zich volledig focust op Software Security richten wij ons op oplossingen van het probleem op verschillende niveaus: Developer niveau (white box), QA of Security Auditor niveau (grey box*) en op zeer korte termijn op Operations niveau (runtime). Meer info met betrekking tot Fortify Software: http://www.fortifysoftware.com
* grey box is wanneer je onze technologien in combinatie gebruikt dus application penetration testing (black box) combineren met Source Code Analyse (white box).