Analisten verwelkomen NSA's advies voor ontwikkelaars om geheugenveilige talen te adopteren PlatoBlockchain Data Intelligence. Verticaal zoeken. Ai.

Analisten verwelkomen het advies van de NSA voor ontwikkelaars om geheugenveilige talen te gebruiken

Beveiligingsanalisten verwelkomden vorige week een aanbeveling van de Amerikaanse National Security Agency (NSA) aan softwareontwikkelaars om te overwegen talen zoals C#, Go, Java, Ruby, Rust en Swift te gebruiken om geheugengerelateerde kwetsbaarheden in code te verminderen.

De NSA beschreef deze als "geheugenveilige" talen die het geheugen automatisch beheren als onderdeel van de computertaal. Ze vertrouwen niet op de programmeur om geheugenbeveiliging te implementeren en gebruiken in plaats daarvan een combinatie van compilatietijd- en runtimecontroles om te beschermen tegen geheugenfouten, aldus de NSA.

De zaak voor geheugenveilige talen

Het enigszins ongebruikelijke advies van de NSA van 10 november wees op veelgebruikte talen zoals C en C++ als te veel leunen op programmeurs om geen geheugengerelateerde fouten te maken, wat volgens het bedrijf nog steeds de belangrijkste oorzaak is van beveiligingsproblemen in software. Eerdere studies - een door Microsoft anno 2019 en een andere uit Google anno 2020 gerelateerd aan de Chrome-browser - beide vonden bijvoorbeeld dat 70% van de kwetsbaarheden geheugenveiligheidsproblemen waren, aldus de NSA.

"Veelgebruikte talen, zoals C en C++, bieden veel vrijheid en flexibiliteit bij geheugenbeheer, terwijl ze sterk afhankelijk zijn van de programmeur om de nodige controles op geheugenreferenties uit te voeren", aldus de NSA. Dit resulteert vaak in exploiteerbare kwetsbaarheden die verband houden met eenvoudige fouten, zoals bufferoverloopfouten, problemen met geheugentoewijzing en racecondities.

C#, Go, Java, Ruby, Rust, Swift en andere geheugenveilige talen sluiten het risico van deze problemen niet volledig uit, aldus de NSA in haar advies. De meeste bevatten bijvoorbeeld ten minste een paar klassen of functies die niet geheugenveilig zijn en die de programmeur in staat stellen een potentieel onveilige geheugenbeheerfunctie uit te voeren. Geheugenveilige talen kunnen soms ook bibliotheken bevatten die zijn geschreven in talen die potentieel onveilige geheugenfuncties bevatten.

Maar zelfs met deze voorbehouden, geheugenveilige talen kan helpen om kwetsbaarheden in software te verminderen als gevolg van slecht en onzorgvuldig geheugenbeheer, aldus de NSA.

Tim Mackey, hoofdbeveiligingsstrateeg bij Synopsys Cybersecurity Research Center, verwelkomt de aanbeveling van de NSA. Het gebruik van geheugenveilige talen zou eigenlijk de standaard moeten zijn voor de meeste toepassingen, zegt hij. "Voor praktische doeleinden betekent het vertrouwen op ontwikkelaars om zich te concentreren op problemen met geheugenbeheer in plaats van coole nieuwe functies te programmeren, een belasting op innovatie", zegt hij. Met geheugenveilige programmeertalen en bijbehorende frameworks zijn het de auteurs van de taal die zorgen voor goed geheugenbeheer en niet de applicatieontwikkelaars, zegt Mackey.

Verschuiving kan een uitdaging zijn

Het verplaatsen van een volwassen software-ontwikkelomgeving van de ene taal naar de andere kan moeilijk zijn, erkende de NSA. Programmeurs zullen de nieuwe taal moeten leren, en er zullen waarschijnlijk nieuwelingenfouten en efficiëntiehits zijn tijdens het proces. De mate van geheugenbeveiliging die beschikbaar is, kan ook aanzienlijk verschillen per taal. Sommige bieden misschien slechts minimale geheugenbeveiliging, terwijl andere aanzienlijke bescherming bieden rond geheugentoegang, toewijzing en beheer.

Bovendien zullen organisaties moeten overwegen hoeveel afwegingen ze willen maken tussen beveiliging en prestaties. "Geheugenveiligheid kan kostbaar zijn qua prestaties en flexibiliteit", waarschuwde de NSA. "Voor talen met een extreem niveau van inherente bescherming kan vanwege de controles en beveiligingen veel werk nodig zijn om het programma gewoon te laten compileren."

Er zijn talloze variabelen in het spel bij het overzetten van een applicatie van de ene taal naar de andere, zegt Mike Parkin, senior technisch ingenieur bij Vulcan Cyber. "In het beste geval is de overstap eenvoudig en kan een organisatie deze relatief pijnloos uitvoeren", zegt Parkin. "In andere gevallen vertrouwt de applicatie op functies die triviaal zijn in de originele taal, maar uitgebreide en dure ontwikkeling vereisen om opnieuw te creëren in de nieuwe taal."

Het gebruik van geheugenveilige talen vervangt ook niet de noodzaak van het goed testen van software, waarschuwt Mackey. Alleen omdat een programmeertaal geheugenveilig is, wil nog niet zeggen dat de taal of applicaties die erop zijn ontwikkeld vrij zijn van bugs.

Overstappen van de ene programmeertaal naar de andere is riskant, tenzij je personeel hebt dat zowel de oude als de nieuwe taal begrijpt, zegt Mackey. “Een dergelijke migratie kan het beste worden uitgevoerd wanneer de applicatie een grote versie-update doormaakt; anders bestaat de kans dat er onbedoelde bugs worden geïntroduceerd als onderdeel van de migratie-inspanningen”, merkt hij op.

Mackey stelt voor dat organisaties overwegen om microservices te gebruiken als het gaat om het verschuiven van talen. "Met een microservices-architectuur wordt de applicatie ontleed in een set services die in containers zijn ondergebracht", zegt Mackey. "Vanuit het perspectief van een programmeertaal is er niets dat inherent vereist dat elke microservice in dezelfde programmeertaal wordt geprogrammeerd als andere services binnen dezelfde applicatie."

De beweging maken

Dat blijkt uit recente gegevens van Statista veel ontwikkelaars gebruiken het al talen die als geheugenveilig worden beschouwd. Bijna tweederde (65.6%) gebruikt bijvoorbeeld JavaScript, bijna de helft (48.06%) gebruikt Python, een derde gebruikt Java en bijna 28% gebruikt C#. Tegelijkertijd gebruikt een aanzienlijk deel nog steeds onveilige talen zoals C++ (22.5%) en C (19.25%).

"Ik denk dat veel organisaties al zijn overgestapt van C/C++, niet alleen vanwege de geheugenveiligheid, maar ook vanwege het algehele gemak van ontwikkeling en onderhoud", zegt Johannes Ullrich, onderzoeksdecaan van het SANS Technology Institute. "Maar er zullen nog steeds oude codebases zijn die nog vele jaren moeten worden onderhouden."

Het advies van de NSA bood weinig inzicht in wat de aanleiding zou kunnen zijn geweest voor haar aanbeveling op dit moment. Maar John Bambenek, hoofddreigingsjager bij Netenrich, adviseert organisaties om dit niet te negeren. "Geheugenkwetsbaarheden en -aanvallen zijn alomtegenwoordig sinds de jaren negentig, dus over het algemeen is dit een goed advies", zegt hij. "Met dat gezegd zijnde, aangezien dit afkomstig is van de NSA, denk ik dat dit advies extra dringend moet zijn en wordt gedreven door kennis die zij hebben en wij niet."

Tijdstempel:

Meer van Donkere lezing