Analysts Welcome NSA's Advice for Developers to Adopt Memory-Safe Languages PlatoBlockchain Data Intelligence. Vertical Search. Ai.

Az elemzők üdvözlik az NSA tanácsát a fejlesztőknek a memóriabiztos nyelvek elfogadására

Biztonsági elemzők üdvözölték az Egyesült Államok Nemzetbiztonsági Ügynökségének (NSA) múlt héten azt a javaslatát, hogy a szoftverfejlesztők fontolják meg olyan nyelvek átvételét, mint a C#, Go, Java, Ruby, Rust és Swift, hogy csökkentsék a kód memóriával kapcsolatos sérülékenységeit.

Az NSA ezeket „memóriabiztos” nyelveknek nevezte, amelyek a számítógépes nyelv részeként automatikusan kezelik a memóriát. Nem hagyatkoznak a programozóra a memóriabiztonság megvalósításában, hanem a fordítási idő és a futási idő ellenőrzésének kombinációját használják a memóriahibák elleni védelem érdekében – közölte az NSA.

A memóriabiztos nyelvek esete

Az NSA kissé szokatlan, november 10-i tanácsadója rámutatott az olyan széles körben használt nyelvekre, mint a C és a C++, mint pl. túlságosan a programozókra támaszkodik Megjegyezte, hogy ne kövessünk el memóriával kapcsolatos hibákat, ami továbbra is a szoftverek biztonsági réseinek legfőbb oka. Korábbi tanulmányok – egyenként A Microsoft 2019-ben és egy másik A Google 2020-ban Az NSA szerint például a sebezhetőségek 70%-a memóriabiztonsági probléma volt.

"Az általánosan használt nyelvek, mint például a C és a C++, nagy szabadságot és rugalmasságot biztosítanak a memóriakezelésben, miközben nagymértékben támaszkodnak a programozóra a memóriahivatkozások szükséges ellenőrzéseinek elvégzésében" - mondta az NSA. Ez gyakran olyan kihasználható sebezhetőségeket eredményez, amelyek egyszerű hibákhoz kötődnek, például puffertúlcsordulási hibákhoz, memóriafoglalási problémákhoz és versenyfeltételekhez.

A C#, a Go, a Java, a Ruby, a Rust, a Swift és más memóriabiztos nyelvek nem zárják ki teljesen ezeknek a problémáknak a kockázatát – áll az NSA tanácsadójában. Legtöbbjük például tartalmaz legalább néhány olyan osztályt vagy függvényt, amelyek nem biztonságosak a memória számára, és lehetővé teszik a programozó számára, hogy potenciálisan nem biztonságos memóriakezelési funkciót hajtson végre. A memóriabiztos nyelvek néha olyan nyelveken írt könyvtárakat is tartalmazhatnak, amelyek potenciálisan nem biztonságos memóriafunkciókat tartalmaznak.

De még ezekkel a figyelmeztetésekkel is, memóriabiztos nyelvek segíthet csökkenteni a szoftverek sebezhetőségét az NSA szerint a rossz és gondatlan memóriakezelés eredménye.

Tim Mackey, a Synopsys Cybersecurity Research Center vezető biztonsági stratégája üdvözli az NSA ajánlását. A legtöbb alkalmazásnál a memóriabiztos nyelvek használatának kell lennie az alapértelmezettnek, mondja. „Gyakorlati okokból, ha a fejlesztőkre hagyatkozunk, hogy a memóriakezelési problémákra összpontosítsanak, ahelyett, hogy új funkciókat programoznának, az innovációs adót jelent” – mondja. A memóriabiztos programozási nyelvek és a kapcsolódó keretrendszerek esetében a megfelelő memóriakezelést a nyelv szerzői biztosítják, nem pedig az alkalmazásfejlesztők – mondja Mackey.

A váltás kihívást jelenthet

Az NSA elismerte, hogy nehéz lehet egy kiforrott szoftverfejlesztő környezetet egyik nyelvről a másikra átállítani. A programozóknak meg kell tanulniuk az új nyelvet, és valószínűleg lesznek újoncok hibái és hatékonysági ütések a folyamat során. A rendelkezésre álló memóriabiztonság mértéke nyelvenként is jelentősen változhat. Egyesek csak minimális memóriabiztonságot kínálnak, míg mások jelentős védelmet nyújtanak a memóriaelérés, -allokáció és -kezelés terén.

Ezenkívül a szervezeteknek mérlegelniük kell, hogy mekkora kompromisszumot hajlandóak kötni a biztonság és a teljesítmény között. „A memória biztonsága költséges lehet a teljesítmény és a rugalmasság tekintetében” – figyelmeztetett az NSA. "Az extrém szintű belső védelemmel rendelkező nyelvek esetében az ellenőrzések és védelmek miatt jelentős munkára lehet szükség ahhoz, hogy a programot egyszerűen lefordítsák."

Mike Parkin, a Vulcan Cyber ​​vezető műszaki mérnöke, számtalan változó játszik szerepet, amikor egy alkalmazást egyik nyelvről a másikra próbálunk átportolni. „A legjobb esetben a váltás egyszerű, és egy szervezet viszonylag fájdalommentesen tudja végrehajtani” – mondja Parkin. „Más esetekben az alkalmazás olyan funkciókra támaszkodik, amelyek az eredeti nyelven triviálisak, de az újban való újraalkotáshoz kiterjedt és költséges fejlesztésre van szükség.”

Mackey figyelmeztet, hogy a memóriabiztos nyelvek használata nem helyettesíti a megfelelő szoftvertesztelés szükségességét. Csak azért, mert egy programozási nyelv memóriabiztos, még nem jelenti azt, hogy a nyelv vagy az azon fejlesztett alkalmazások mentesek a hibáktól.

Az egyik programozási nyelvről a másikra való átállás kockázatos javaslat, hacsak nincs olyan alkalmazottja, aki már érti a régi és az új nyelvet is, mondja Mackey. „Az ilyen áttelepítést akkor lehet a legjobban végrehajtani, ha az alkalmazás egy jelentős verziófrissítésen megy keresztül; ellenkező esetben fennáll annak a lehetősége, hogy a migrációs erőfeszítés részeként véletlen hibákat vezetnek be” – jegyzi meg.

Mackey azt javasolja, hogy a szervezetek fontolják meg a mikroszolgáltatások használatát, amikor nyelvváltásról van szó. „A mikroszolgáltatási architektúrával az alkalmazás konténeres szolgáltatásokra bomlik” – mondja Mackey. "Egy programozási nyelv szemszögéből semmi sem követeli meg, hogy minden mikroszolgáltatást ugyanazon a programozási nyelven programozzanak, mint az ugyanazon alkalmazáson belüli többi szolgáltatást."

Mozgás

A Statista friss adatai ezt mutatják sok fejlesztő már használja memóriabiztonságnak számító nyelvek. Közel kétharmada (65.6%) például JavaScriptet, közel fele (48.06%) Pythont, egyharmada Java-t, és közel 28%-a C#-t használ. Ugyanakkor jelentős arányban még mindig nem biztonságos nyelveket használnak, mint például a C++ (22.5%) és C (19.25%).

„Úgy gondolom, hogy sok szervezet már nem csak a memóriabiztonság miatt vált le a C/C++-ról, hanem a fejlesztés és karbantartás általános egyszerűsége miatt is” – mondja Johannes Ullrich, a SANS Technology Institute kutatási dékánja. "De továbbra is lesznek örökölt kódalapok, amelyeket még sok éven át fenn kell tartani."

Az NSA tanácsadója kevés betekintést engedett abba, hogy ezen a ponton mi indokolhatta ajánlását. John Bambenek, a Netenrich fő fenyegetésvadásza azonban azt tanácsolja, hogy a szervezetek ne hagyják figyelmen kívül. "A memória sebezhetősége és támadásai az 1990-es évek óta terjedtek, így általában ez egy jó tanács" - mondja. „Ezzel együtt, mivel ez az NSA-tól érkezik, úgy gondolom, hogy ennek a tanácsnak még sürgősebbnek kell lennie, és az általuk birtokolt tudás vezérli, mi pedig nem.”

Időbélyeg:

Még több Sötét olvasmány