Sikkerhedsanalytikere hilste en anbefaling fra US National Security Agency (NSA) i sidste uge til softwareudviklere om at overveje at adoptere sprog som C#, Go, Java, Ruby, Rust og Swift for at reducere hukommelsesrelaterede sårbarheder i kode.
NSA beskrev disse som "hukommelsessikre" sprog, der styrer hukommelsen automatisk som en del af computersproget. De er ikke afhængige af programmøren til at implementere hukommelsessikkerhed og bruger i stedet en kombination af kompileringstid og kørselstidstjek for at beskytte mod hukommelsesfejl, sagde NSA.
Sagen om hukommelsessikre sprog
NSA's noget usædvanlige rådgivning den 10. november pegede på udbredte sprog som C og C++ som stoler for meget på programmører ikke at lave hukommelsesrelaterede fejl, som den bemærkede, fortsat er den største årsag til sikkerhedssårbarheder i software. Tidligere undersøgelser - en efter Microsoft i 2019 og en anden fra Google i 2020 relateret til dens Chrome-browser – for eksempel fandt begge, at 70 % af sårbarhederne var problemer med hukommelsessikkerhed, sagde NSA.
"Almindelig brugte sprog, såsom C og C++, giver en masse frihed og fleksibilitet i hukommelsesstyring, mens de er stærkt afhængige af programmøren til at udføre de nødvendige kontroller af hukommelsesreferencer," sagde NSA. Dette resulterer ofte i sårbarheder, der kan udnyttes, bundet til simple fejl, såsom bufferoverløbsfejl, problemer med hukommelsesallokering og raceforhold.
C#, Go, Java, Ruby, Rust, Swift og andre hukommelsessikre sprog eliminerer ikke fuldstændigt risikoen for disse problemer, sagde NSA i sin rådgivning. De fleste af dem, for eksempel, inkluderer mindst et par klasser eller funktioner, der er ikke-hukommelsessikre og tillader programmøren at udføre en potentielt usikker hukommelsesstyringsfunktion. Hukommelsessikre sprog kan nogle gange også omfatte biblioteker skrevet på sprog, der indeholder potentielt usikre hukommelsesfunktioner.
Men selv med disse forbehold er hukommelsessikre sprog kan hjælpe med at reducere sårbarheder i software som følge af dårlig og skødesløs hukommelseshåndtering, sagde NSA.
Tim Mackey, ledende sikkerhedsstrateg ved Synopsys Cybersecurity Research Center, hilser NSA's anbefaling velkommen. Brugen af hukommelsessikre sprog burde faktisk være standard for de fleste applikationer, siger han. "Af praktiske årsager repræsenterer det en skat på innovation at stole på, at udviklere fokuserer på problemer med hukommelsesstyring i stedet for at programmere fede nye funktioner," siger han. Med hukommelsessikre programmeringssprog og tilhørende frameworks er det forfatterne af sproget, der sikrer korrekt hukommelsesstyring og ikke applikationsudviklerne, siger Mackey.
Skift kan være udfordrende
Det kan være svært at skifte et modent softwareudviklingsmiljø fra et sprog til et andet, erkendte NSA. Programmører bliver nødt til at lære det nye sprog, og der vil sandsynligvis være nybegyndere fejl og effektivitet hits under processen. Omfanget af hukommelsessikkerhed, der er tilgængelig, kan også variere betydeligt fra sprog til sprog. Nogle tilbyder måske kun minimal hukommelsessikkerhed, mens andre tilbyder betydelig beskyttelse omkring hukommelsesadgang, -allokering og -styring.
Derudover skal organisationer overveje, hvor stor en afvejning de er villige til at foretage mellem sikkerhed og ydeevne. "Hukommelsessikkerhed kan være dyrt i ydeevne og fleksibilitet," advarede NSA. "For sprog med et ekstremt niveau af iboende beskyttelse kan det være nødvendigt med betydeligt arbejde for simpelthen at få programmet til at kompilere på grund af kontrollerne og beskyttelserne."
Der er utallige variabler i spil, når man forsøger at portere en applikation fra et sprog til et andet, siger Mike Parkin, senior teknisk ingeniør hos Vulcan Cyber. "I et bedste tilfælde er skiftet enkelt, og en organisation kan opnå det relativt smertefrit," siger Parkin. "I andre er applikationen afhængig af funktioner, der er trivielle på originalsproget, men som kræver omfattende og dyr udvikling at genskabe i det nye."
Brugen af hukommelsessikre sprog erstatter heller ikke behovet for korrekt softwaretest, advarer Mackey. Bare fordi et programmeringssprog er hukommelsessikkert, betyder det ikke, at sproget eller applikationerne udviklet på det er fri for fejl.
At flytte fra et programmeringssprog til et andet er et risikabelt forslag, medmindre du har personale, der allerede forstår både det gamle og det nye, siger Mackey. “En sådan migrering udføres bedst, når applikationen gennemgår en større versionsopdatering; ellers er der potentiale for, at utilsigtede fejl introduceres som en del af migrationsindsatsen,” bemærker han.
Mackey foreslår, at organisationer overvejer at bruge mikrotjenester, når det kommer til at skifte sprog. "Med en mikroservicearkitektur er applikationen opdelt i et sæt tjenester, der er containeriseret," siger Mackey. "Fra et programmeringssprogs perspektiv er der intet, der i sagens natur kræver, at hver mikrotjeneste programmeres i det samme programmeringssprog som andre tjenester inden for samme applikation."
Gøre flytningen
Det viser de seneste data fra Statista mange udviklere bruger allerede sprog, der betragtes som hukommelsessikre. Næsten to tredjedele (65.6 %) bruger for eksempel JavaScript, næsten halvdelen (48.06 %) bruger Python, en tredjedel bruger Java, og næsten 28 % bruger C#. Samtidig bruger en betydelig del stadig usikre sprog som C++ (22.5 %) og C (19.25 %).
"Jeg tror, at mange organisationer allerede har skiftet væk fra C/C++, ikke kun på grund af hukommelsessikkerhedsspørgsmålet, men også for den overordnede lette udvikling og vedligeholdelse," siger Johannes Ullrich, forskningsdekan ved SANS Technology Institute. "Men der vil stadig være ældre kodebaser, som skal vedligeholdes i mange år fremover."
NSA's rådgivning gav ringe indsigt i, hvad der kunne have foranlediget dens anbefaling på dette tidspunkt. Men John Bambenek, hovedtrusselsjæger hos Netenrich, råder organisationer til ikke at ignorere det. "Hukommelsessårbarheder og -angreb har været gennemgående siden 1990'erne, så generelt er dette et godt råd," siger han. "Med det sagt, da dette kommer fra NSA, mener jeg, at dette råd bør tage ekstra hastende karakter og er drevet af viden, de har, og det har vi ikke."
