Analiștii salută sfatul NSA pentru dezvoltatori de a adopta limbaje sigure pentru memorie

Analiștii de securitate au salutat săptămâna trecută o recomandare din partea Agenției Naționale de Securitate a SUA (NSA) pentru dezvoltatorii de software să ia în considerare adoptarea de limbaje precum C#, Go, Java, Ruby, Rust și Swift pentru a reduce vulnerabilitățile legate de memorie în cod.

NSA le-a descris ca fiind limbi „sigure pentru memorie” care gestionează memoria automat ca parte a limbajului computerului. Ei nu se bazează pe programator pentru a implementa securitatea memoriei și, în schimb, folosesc o combinație de verificări ale timpului de compilare și ale timpului de rulare pentru a se proteja împotriva erorilor de memorie, a spus NSA.

Cazul pentru limbi sigure pentru memorie

Avizul oarecum neobișnuit al NSA din 10 noiembrie a subliniat limbaje utilizate pe scară largă precum C și C++ ca bazându-se prea mult pe programatori a nu face greșeli legate de memorie, despre care a remarcat, continuă să fie principala cauză a vulnerabilităților de securitate în software. Studii anterioare — unul de Microsoft în 2019 și altul de la Google în 2020 legate de browserul său Chrome — de exemplu, ambele au descoperit că 70% dintre vulnerabilități erau probleme de siguranță a memoriei, a spus NSA.

„Limbajele utilizate în mod obișnuit, cum ar fi C și C++, oferă multă libertate și flexibilitate în gestionarea memoriei, în timp ce se bazează foarte mult pe programator pentru a efectua verificările necesare referințelor de memorie”, a spus NSA. Acest lucru duce adesea la vulnerabilități exploatabile legate de greșeli simple, cum ar fi erori de depășire a memoriei tampon, probleme de alocare a memoriei și condiții de cursă.

C#, Go, Java, Ruby, Rust, Swift și alte limbaje sigure pentru memorie nu elimină complet riscul acestor probleme, a spus NSA în avizul său. Cele mai multe dintre ele, de exemplu, includ cel puțin câteva clase sau funcții care nu sunt sigure pentru memorie și permit programatorului să efectueze o funcție de gestionare a memoriei potențial nesigură. Limbile sigure pentru memorie pot include uneori și biblioteci scrise în limbi care conțin funcții de memorie potențial nesigure.

Dar chiar și cu aceste avertismente, limbi sigure pentru memorie poate ajuta la reducerea vulnerabilităților în software rezultat din gestionarea slabă și neglijentă a memoriei, a spus NSA.

Tim Mackey, strateg principal de securitate la Synopsys Cybersecurity Research Center, salută recomandarea NSA. Utilizarea limbajelor sigure pentru memorie ar trebui, de fapt, să fie implicită pentru majoritatea aplicațiilor, spune el. „În scopuri practice, bazarea pe dezvoltatori pentru a se concentra pe problemele de gestionare a memoriei în loc să programeze noi funcții interesante reprezintă o taxă asupra inovației”, spune el. Cu limbaje de programare sigure pentru memorie și cadre asociate, autorii limbajului sunt cei care asigură gestionarea adecvată a memoriei și nu dezvoltatorii de aplicații, spune Mackey.

Schimbarea poate fi provocatoare

Schimbarea unui mediu matur de dezvoltare software de la o limbă la alta poate fi dificilă, a recunoscut NSA. Programatorii vor trebui să învețe noua limbă și, probabil, vor exista greșeli pentru începători și succese de eficiență în timpul procesului. Gradul de securitate a memoriei disponibilă poate varia semnificativ în funcție de limbă. Unele ar putea oferi doar o securitate minimă a memoriei, în timp ce altele oferă protecții considerabile în ceea ce privește accesul, alocarea și gestionarea memoriei.

În plus, organizațiile vor trebui să ia în considerare cât de mult compromis sunt dispuse să facă între securitate și performanță. „Siguranța memoriei poate fi costisitoare în performanță și flexibilitate”, a avertizat NSA. „Pentru limbile cu un nivel extrem de protecție inerentă, este posibil să fie nevoie de muncă considerabilă pentru ca programul să fie compilat, datorită verificărilor și protecțiilor.”

Există o mulțime de variabile în joc atunci când se încearcă portarea unei aplicații dintr-o limbă în alta, spune Mike Parkin, inginer tehnic senior la Vulcan Cyber. „În cel mai bun scenariu, schimbarea este simplă, iar o organizație o poate realiza relativ fără durere”, spune Parkin. „În altele, aplicația se bazează pe caracteristici care sunt banale în limba originală, dar necesită o dezvoltare extinsă și costisitoare pentru a fi recreată în limba nouă.”

Utilizarea limbilor sigure pentru memorie, de asemenea, nu înlocuiește nevoia de testare adecvată a software-ului, avertizează Mackey. Doar pentru că un limbaj de programare este sigur pentru memorie, nu înseamnă că limbajul sau aplicațiile dezvoltate pe el sunt lipsite de erori.

Trecerea de la un limbaj de programare la altul este o propunere riscantă, cu excepția cazului în care aveți personal care înțelege deja atât limbajul vechi, cât și pe cel nou, spune Mackey. „O astfel de migrare se face cel mai bine atunci când aplicația trece printr-o actualizare majoră a versiunii; în caz contrar, există potențialul ca erori involuntare să fie introduse ca parte a efortului de migrare”, notează el.

Mackey sugerează ca organizațiile să ia în considerare utilizarea microserviciilor atunci când vine vorba de schimbarea limbilor. „Cu o arhitectură de microservicii, aplicația este descompusă într-un set de servicii care sunt containerizate”, spune Mackey. „Din perspectiva unui limbaj de programare, nu există nimic care să solicite în mod inerent ca fiecare microserviciu să fie programat în același limbaj de programare ca și alte servicii din aceeași aplicație.”

Efectuarea mișcării

Datele recente de la Statista arată asta mulți dezvoltatori folosesc deja limbi care sunt considerate sigure pentru memorie. De exemplu, aproape două treimi (65.6%) folosesc JavaScript, aproape jumătate (48.06%) folosesc Python, o treime utilizează Java și aproape 28% folosesc C#. În același timp, o proporție substanțială utilizează încă limbaje nesigure, cum ar fi C++ (22.5%) și C (19.25%).

„Cred că multe organizații au renunțat deja la C/C++ nu numai din cauza siguranței memoriei, ci și pentru ușurința generală de dezvoltare și întreținere”, spune Johannes Ullrich, decanul de cercetare la Institutul de Tehnologie SANS. „Dar vor exista în continuare baze de coduri moștenite care vor trebui menținute mulți ani de acum înainte.”

Avizul NSA a oferit puține informații despre ceea ce ar fi putut determina recomandarea sa în acest moment. Dar John Bambenek, principalul vânător de amenințări la Netenrich, sfătuiește ca organizațiile să nu o ignore. „Vulnerabilitățile și atacurile de memorie au fost omniprezente din anii 1990, așa că, în general, acesta este un sfat bun”, spune el. „Cu toate acestea, deoarece acest lucru vine de la NSA, cred că acest sfat ar trebui să fie mai urgent și este condus de cunoștințele pe care le au și noi nu.”