Säkerhetsanalytiker välkomnade en rekommendation från US National Security Agency (NSA) förra veckan till programvaruutvecklare att överväga att använda språk som C#, Go, Java, Ruby, Rust och Swift för att minska minnesrelaterade sårbarheter i kod.
NSA beskrev dessa som "minnessäkra" språk som hanterar minne automatiskt som en del av datorspråket. De litar inte på programmeraren för att implementera minnessäkerhet utan använder istället en kombination av kompileringstid och körtidskontroller för att skydda mot minnesfel, sa NSA.
Fallet för minnessäkra språk
NSA:s något ovanliga råd den 10 november pekade på allmänt använda språk som C och C++ som förlitar sig för mycket på programmerare att inte göra minnesrelaterade misstag, vilket den noterade, fortsätter att vara den främsta orsaken till säkerhetssårbarheter i programvara. Tidigare studier — en efter Microsoft 2019 och en annan från Google 2020 relaterat till Chrome-webbläsaren – till exempel fann båda att 70 % av sårbarheterna var minnessäkerhetsproblem, sa NSA.
"Vanligt använda språk, som C och C++, ger mycket frihet och flexibilitet i minneshantering samtidigt som de förlitar sig starkt på programmeraren för att utföra de nödvändiga kontrollerna av minnesreferenser", sa NSA. Detta resulterar ofta i exploateringsbara sårbarheter kopplade till enkla misstag som buffertspillfel, problem med minnesallokering och tävlingsförhållanden.
C#, Go, Java, Ruby, Rust, Swift och andra minnessäkra språk eliminerar inte helt risken för dessa problem, sade NSA i sin rådgivning. De flesta av dem, till exempel, inkluderar åtminstone ett fåtal klasser eller funktioner som är icke-minnessäkra och tillåter programmeraren att utföra en potentiellt osäker minneshanteringsfunktion. Minnessäkra språk kan ibland även innehålla bibliotek skrivna på språk som innehåller potentiellt osäkra minnesfunktioner.
Men även med dessa varningar, minnessäkra språk kan hjälpa till att minska sårbarheter i programvara till följd av dålig och slarvig minneshantering, sa NSA.
Tim Mackey, huvudsäkerhetsstrateg vid Synopsys Cybersecurity Research Center, välkomnar NSA:s rekommendation. Användningen av minnessäkra språk borde i själva verket vara standard för de flesta applikationer, säger han. "För praktiska ändamål, att förlita sig på att utvecklare fokuserar på minneshanteringsfrågor istället för att programmera coola nya funktioner representerar en skatt på innovation", säger han. Med minnessäkra programmeringsspråk och tillhörande ramverk är det författarna till språket som säkerställer korrekt minneshantering och inte applikationsutvecklarna, säger Mackey.
Skift kan vara utmanande
Att flytta en mogen mjukvaruutvecklingsmiljö från ett språk till ett annat kan vara svårt, erkände NSA. Programmerare kommer att behöva lära sig det nya språket, och det kommer sannolikt att bli nybörjarmisstag och effektivitetsträffar under processen. Omfattningen av minnessäkerhet som är tillgänglig kan också variera avsevärt beroende på språk. Vissa kanske bara erbjuder minimal minnessäkerhet, medan andra erbjuder betydande skydd kring minnesåtkomst, allokering och hantering.
Dessutom kommer organisationer att behöva överväga hur stor avvägning de är villiga att göra mellan säkerhet och prestanda. "Minnessäkerhet kan vara dyrt i prestanda och flexibilitet", varnade NSA. "För språk med en extrem nivå av inneboende skydd kan det behövas mycket arbete för att helt enkelt få programmet att kompilera på grund av kontrollerna och skydden."
Det finns otaliga variabler i spel när man försöker porta en applikation från ett språk till ett annat, säger Mike Parkin, senior teknisk ingenjör på Vulcan Cyber. "I bästa fall är förändringen enkel, och en organisation kan åstadkomma det relativt smärtfritt," säger Parkin. "I andra bygger applikationen på funktioner som är triviala på originalspråket men som kräver omfattande och dyr utveckling för att återskapa i det nya."
Användningen av minnessäkra språk ersätter inte heller behovet av korrekt mjukvarutestning, varnar Mackey. Bara för att ett programmeringsspråk är minnessäkert betyder det inte att språket eller applikationerna som utvecklats på det är fria från buggar.
Att flytta från ett programmeringsspråk till ett annat är ett riskabelt förslag om du inte har personal som redan förstår både det gamla och det nya, säger Mackey. ”En sådan migrering görs bäst när applikationen genomgår en större versionsuppdatering; annars finns det risk för att oavsiktliga buggar introduceras som en del av migreringsarbetet”, konstaterar han.
Mackey föreslår att organisationer överväger att använda mikrotjänster när det gäller att byta språk. "Med en mikroservicearkitektur bryts applikationen upp i en uppsättning tjänster som är containeriserade," säger Mackey. "Ur ett programmeringsspråks perspektiv finns det inget som i sig kräver att varje mikrotjänst programmeras i samma programmeringsspråk som andra tjänster inom samma applikation."
Gör flytten
Färska uppgifter från Statista visar det många utvecklare använder redan språk som anses vara minnessäkra. Nästan två tredjedelar (65.6 %) använder till exempel JavaScript, nästan hälften (48.06 %) använder Python, en tredjedel använder Java och nästan 28 % använder C#. Samtidigt använder en betydande andel fortfarande osäkra språk som C++ (22.5 %) och C (19.25 %).
"Jag tror att många organisationer redan har bytt bort från C/C++, inte bara för minnessäkerhetsfrågan, utan också för den övergripande lättheten att utveckla och underhålla", säger Johannes Ullrich, forskningsdekanus vid SANS Technology Institute. "Men det kommer fortfarande att finnas äldre kodbaser som kommer att behöva underhållas i många år framöver."
NSA:s råd erbjöd liten insikt i vad som kan ha föranlett dess rekommendation vid denna tidpunkt. Men John Bambenek, huvudhotsjägare på Netenrich, rekommenderar att organisationer inte ignorerar det. "Sårbarheter och attacker i minnet har varit genomgående sedan 1990-talet, så generellt sett är detta ett bra råd", säger han. "Med det sagt, eftersom det här kommer från NSA, tror jag att detta råd borde vara extra brådskande och drivs av kunskap de har och det har vi inte."
