NSA als desenvolupadors: penseu en canviar de C i C++ a un llenguatge de programació segur per a la memòria

Imatge: Getty Images/iStockphoto

L’Agència de Seguretat Nacional (NSA) insta els desenvolupadors a canviar a llenguatges segurs de memòria, com ara C#, Go, Java, Ruby, Rust i Swift, per protegir el seu codi de l’execució de codi remota o altres atacs de pirates informàtics.

Dels idiomes esmentats anteriorment, Java és el més utilitzat en el desenvolupament d’aplicacions empresarials i d’Android, mentre que Swift és un dels 10 idiomes principals, gràcies en part al desenvolupament d’aplicacions per a iOS. I hi ha un interès creixent per Rust com a substitut de C i C++ en la programació de sistemes.

“NSA aconsella a les organitzacions que considerin fer un canvi estratègic de llenguatges de programació que proporcionen poca o cap protecció de memòria inherent, com C/C++, a un llenguatge segur de memòria quan sigui possible. Alguns exemples de llenguatges segurs de memòria són C#, Go. , Java, Ruby i Swift”, va dir la NSA.

L’agència d’espionatge cita investigacions recents de Google i Microsoft que el 70% dels seus problemes de seguretat, respectivament a Chrome i Windows, estaven relacionats amb la memòria i molts d’ells van ser el resultat de l’ús de C i C++, que són més propensos a les vulnerabilitats basades en la memòria. .

També: Ciberseguretat, núvol i codificació: per què aquestes tres habilitats lideraran la demanda el 2023

“Els ciberactors maliciosos poden explotar aquestes vulnerabilitats per a l’execució remota de codi o altres efectes adversos, que sovint poden comprometre un dispositiu i ser el primer pas en les intrusions de xarxa a gran escala”, assenyala l’NSA al full d’informació de ciberseguretat “Seguretat de la memòria del programari”.

“Els llenguatges d’ús habitual, com ara C i C++, proporcionen molta llibertat i flexibilitat en la gestió de la memòria alhora que depenen molt del programador per realitzar les comprovacions necessàries a les referències de memòria”.

Per tant, l’agència recomana utilitzar un llenguatge segur de memòria sempre que sigui possible, ja sigui per al desenvolupament d’aplicacions o per a la programació de sistemes.

“La NSA recomana utilitzar un llenguatge segur de memòria quan sigui possible”, assenyala.

Tot i que la majoria dels professionals de l’infosec estan familiaritzats amb aquest debat sobre els llenguatges segurs per a la memòria, potser no tots els desenvolupadors ho estan. Tot i que potser haurien de ser-ho, atès que es tracta d’un problema de dècades, com va assenyalar recentment el creador de Java James Gosling en una discussió sobre com i per què es va crear Java.

En tot cas, el document de la NSA ofereix als desenvolupadors una explicació clara i senzilla de les raons tècniques darrere de passar cap a llenguatges segurs per a la memòria. Probablement el llenguatge més discutit pel que fa a la seguretat de la memòria ha estat Rust, que és el principal candidat com a “reemplaçament” de C i C++.

El nucli de Linux va introduir recentment Rust com a segon llenguatge a C, seguint el projecte de codi obert d’Android. Aquests projectes no substituiran el codi C/C++ antic, però preferiran Rust per al codi nou. A més, el CTO de Microsoft Azure Mark Russinovich va demanar recentment a tots els desenvolupadors que utilitzessin Rust sobre C i C++ per a tots els projectes nous.

“En explotar aquest tipus de problemes de memòria, els actors maliciosos, que no estan subjectes a les expectatives normals d’ús del programari, poden trobar que poden introduir entrades inusuals al programa, fent que s’accedeixi a la memòria, s’escrigui, s’assigni o es desassigni de maneres inesperades. “, explica la NSA.

Però, com han assenyalat els experts en els debats sobre Rust i C/C++, la NSA adverteix que el simple fet d’utilitzar un llenguatge segur per a la memòria no impedeix per defecte la introducció d’errors de memòria al programari. A més, els idiomes sovint permeten biblioteques que no estan escrites en idiomes segurs per a la memòria.

“Fins i tot amb un llenguatge segur per a la memòria, la gestió de la memòria no és totalment segura. La majoria dels llenguatges segurs per a la memòria reconeixen que de vegades el programari necessita realitzar una funció de gestió de memòria no segura per dur a terme determinades tasques. Com a resultat, hi ha classes o funcions disponibles que estan disponibles. reconegut com a no segur per a la memòria i permetre al programador realitzar una tasca de gestió de memòria potencialment insegura”, va dir la NSA.

“Alguns idiomes requereixen que qualsevol cosa que sigui insegura per a la memòria s’anoti explícitament com a tal perquè el programador i els revisors del programa siguin conscients que no és segur. Els llenguatges segurs per a la memòria també poden utilitzar biblioteques escrites en llenguatges no segurs per a la memòria i per tant, pot contenir una funcionalitat de memòria insegura. Tot i que aquestes maneres d’incloure mecanismes de memòria insegura subverteixen la seguretat de la memòria inherent, ajuden a localitzar on podrien existir problemes de memòria, permetent un escrutini addicional d’aquestes seccions de codi”.

També: Ciberseguretat: aquestes són les novetats de les quals cal preocupar-se el 2023

L’NSA assenyala que alguns idiomes segurs per a la memòria poden tenir un cost de rendiment, que requereix que els desenvolupadors aprenguin un nou idioma. També assenyala que hi ha mesures que els desenvolupadors poden prendre per endurir els llenguatges que no són segurs per a la memòria. L’equip de Chrome de Google, per exemple, està explorant diversos mètodes per endurir C++, però aquests enfocaments també inclouen despeses generals de rendiment. C++ romandrà a la base de codi de Chrome en un futur previsible.

L’NSA recomana proves de seguretat d’aplicacions estàtiques i dinàmiques per detectar problemes de memòria. També recomana explorar mètodes d’enduriment de memòria, com ara Control Flow Guard (CFG), que posarà restriccions sobre on es pot executar el codi. De la mateixa manera, es recomanen l’atzar de disseny de l’espai d’adreces (ASLR) i la prevenció de l’execució de dades (DEP).

Leave a Comment

Your email address will not be published. Required fields are marked *