Gli analisti accolgono con favore il consiglio della NSA per gli sviluppatori di adottare linguaggi sicuri per la memoria

Gli analisti della sicurezza hanno accolto con favore una raccomandazione della National Security Agency (NSA) degli Stati Uniti la scorsa settimana affinché gli sviluppatori di software prendano in considerazione l'adozione di linguaggi come C#, Go, Java, Ruby, Rust e Swift per ridurre le vulnerabilità relative alla memoria nel codice.

La NSA li ha descritti come linguaggi "memory safe" che gestiscono automaticamente la memoria come parte del linguaggio informatico. Non si affidano al programmatore per implementare la sicurezza della memoria e utilizzano invece una combinazione di controlli in fase di compilazione e di esecuzione per proteggersi dagli errori di memoria, ha affermato la NSA.

Il caso dei linguaggi sicuri per la memoria

L'avviso alquanto insolito della NSA del 10 novembre indicava linguaggi ampiamente utilizzati come C e C++ as fare troppo affidamento sui programmatori non commettere errori relativi alla memoria, che ha notato, continua a essere la causa principale delle vulnerabilità di sicurezza nel software. Studi precedenti, uno per Microsoft in 2019 e un altro da Google nel 2020 relativi al suo browser Chrome, ad esempio, entrambi hanno riscontrato che il 70% delle vulnerabilità erano problemi di sicurezza della memoria, ha affermato la NSA.

"I linguaggi di uso comune, come C e C++, offrono molta libertà e flessibilità nella gestione della memoria, facendo molto affidamento sul programmatore per eseguire i controlli necessari sui riferimenti di memoria", ha affermato la NSA. Ciò si traduce spesso in vulnerabilità sfruttabili legate a semplici errori come errori di overflow del buffer, problemi di allocazione della memoria e race condition.

C#, Go, Java, Ruby, Rust, Swift e altri linguaggi sicuri per la memoria non eliminano completamente il rischio di questi problemi, ha affermato la NSA nel suo avviso. La maggior parte di essi, ad esempio, include almeno alcune classi o funzioni che non sono sicure per la memoria e consentono al programmatore di eseguire una funzione di gestione della memoria potenzialmente non sicura. I linguaggi sicuri per la memoria a volte possono anche includere librerie scritte in linguaggi che contengono funzioni di memoria potenzialmente non sicure.

Ma anche con questi avvertimenti, linguaggi sicuri per la memoria può aiutare a ridurre le vulnerabilità nel software derivante da una gestione della memoria scarsa e incurante, ha affermato la NSA.

Tim Mackey, principale stratega della sicurezza presso Synopsys Cybersecurity Research Center, accoglie con favore la raccomandazione della NSA. L'uso di linguaggi sicuri per la memoria dovrebbe, infatti, essere l'impostazione predefinita per la maggior parte delle applicazioni, afferma. "Per scopi pratici, affidarsi agli sviluppatori per concentrarsi sui problemi di gestione della memoria invece di programmare nuove fantastiche funzionalità rappresenta una tassa sull'innovazione", afferma. Con linguaggi di programmazione sicuri per la memoria e framework associati, sono gli autori del linguaggio che garantiscono una corretta gestione della memoria e non gli sviluppatori dell'applicazione, afferma Mackey.

Il cambiamento può essere impegnativo

Spostare un ambiente di sviluppo software maturo da una lingua all'altra può essere difficile, ha riconosciuto la NSA. I programmatori dovranno imparare la nuova lingua e probabilmente ci saranno errori da principianti e colpi di efficienza durante il processo. Anche l'estensione della sicurezza della memoria disponibile può variare in modo significativo in base alla lingua. Alcuni potrebbero offrire solo una minima sicurezza della memoria, mentre altri offrono protezioni considerevoli per l'accesso, l'allocazione e la gestione della memoria.

Inoltre, le organizzazioni dovranno considerare il compromesso che sono disposte a fare tra sicurezza e prestazioni. "La sicurezza della memoria può essere costosa in termini di prestazioni e flessibilità", ha avvertito la NSA. "Per le lingue con un livello estremo di protezione intrinseca, potrebbe essere necessario un lavoro considerevole per ottenere semplicemente la compilazione del programma a causa dei controlli e delle protezioni."

Ci sono una miriade di variabili in gioco quando si tenta di trasferire un'applicazione da una lingua a un'altra, afferma Mike Parkin, ingegnere tecnico senior presso Vulcan Cyber. "Nella migliore delle ipotesi, il passaggio è semplice e un'organizzazione può realizzarlo in modo relativamente indolore", afferma Parkin. "In altri, l'applicazione si basa su funzionalità che sono banali nella lingua originale ma richiedono uno sviluppo esteso e costoso per essere ricreate in quella nuova."

L'uso di linguaggi sicuri per la memoria, inoltre, non sostituisce la necessità di un adeguato test del software, avverte Mackey. Solo perché un linguaggio di programmazione è sicuro per la memoria non significa che il linguaggio o le applicazioni sviluppate su di esso siano esenti da bug.

Passare da un linguaggio di programmazione a un altro è una proposta rischiosa a meno che non si disponga di personale che comprenda già sia il vecchio linguaggio che quello nuovo, afferma Mackey. “Tale migrazione viene eseguita al meglio quando l'applicazione sta attraversando un aggiornamento di versione principale; altrimenti esiste la possibilità che vengano introdotti bug involontari come parte dello sforzo di migrazione", osserva.

Mackey suggerisce che le organizzazioni prendano in considerazione l'utilizzo di microservizi quando si tratta di cambiare lingua. "Con un'architettura di microservizi, l'applicazione viene scomposta in un insieme di servizi containerizzati", afferma Mackey. "Dal punto di vista di un linguaggio di programmazione, non c'è nulla che richieda intrinsecamente che ogni microservizio sia programmato nello stesso linguaggio di programmazione di altri servizi all'interno della stessa applicazione."

Fare la mossa

I dati recenti di Statista lo dimostrano molti sviluppatori stanno già utilizzando lingue considerate sicure per la memoria. Quasi due terzi (65.6%), ad esempio, usa JavaScript, quasi la metà (48.06%) usa Python, un terzo usa Java e quasi il 28% usa C#. Allo stesso tempo, una parte sostanziale utilizza ancora linguaggi non sicuri come C++ (22.5%) e C (19.25%).

"Penso che molte organizzazioni stiano già abbandonando C/C++ non solo per il problema della sicurezza della memoria, ma anche per la facilità complessiva di sviluppo e manutenzione", afferma Johannes Ullrich, decano della ricerca presso il SANS Technology Institute. "Ma ci saranno ancora basi di codice legacy che dovranno essere mantenute per molti anni a venire."

L'avviso della NSA ha offerto poche informazioni su ciò che potrebbe aver spinto la sua raccomandazione in questo frangente. Ma John Bambenek, principale cacciatore di minacce di Netenrich, consiglia alle organizzazioni di non ignorarlo. "Le vulnerabilità e gli attacchi della memoria sono stati pervasivi sin dagli anni '1990, quindi, in generale, questo è un buon consiglio", afferma. "Detto questo, poiché proviene dalla NSA, credo che questo consiglio dovrebbe richiedere ulteriore urgenza ed è guidato dalla conoscenza che hanno e noi no".