Sviluppatori del progetto Chromium 912 vulnerabilità critiche e ad alto rischio identificate nelle versioni stabili di Chrome dal 2015 e hanno concluso che il 70% di esse era causato dall'insicurezza della memoria (errori durante l'utilizzo dei puntatori nel codice C/C++). La metà di questi problemi (36.1%) sono causati da accessi al buffer dopo aver liberato la memoria ad esso associata (use-after-free).
Durante la progettazione di Chromium inizialmente lo era , che è possibile che compaiano errori nel codice, quindi è stata posta grande enfasi sull'uso dell'isolamento sandbox per limitare le conseguenze delle vulnerabilità. Attualmente, le possibilità di utilizzo di questa tecnologia hanno raggiunto il limite delle loro capacità e un'ulteriore frammentazione nei processi è impraticabile dal punto di vista del consumo di risorse.
Per mantenere la sicurezza del codice base, Google applica anche "“, secondo il quale qualsiasi codice aggiunto deve soddisfare non più di due delle tre condizioni: lavorare con dati di input non convalidati, utilizzare un linguaggio di programmazione non sicuro (C/C++) e funzionare con privilegi elevati. Questa regola implica che il codice per l'elaborazione dei dati esterni deve essere ridotto a privilegi minimi (isolato) o scritto in un linguaggio di programmazione sicuro.
Per aumentare ulteriormente la sicurezza del codebase, è stato lanciato un progetto per impedire la comparsa di errori di memoria nel codebase. Esistono tre approcci principali: creare librerie C++ con funzioni per il funzionamento sicuro della memoria ed espandere l'ambito del garbage collector, utilizzando meccanismi di protezione hardware (Memory Tagging Extension) e scrivere componenti in linguaggi che garantiscono un lavoro sicuro con la memoria (Java, Kotlin, JavaScript, Rust, Swift).
Si prevede che il lavoro si concentrerà su due aree:
- Modifica significativa al processo di sviluppo C++, che non esclude un impatto negativo sulle prestazioni (ulteriori controlli dei limiti e garbage collection). Invece dei puntatori grezzi, si propone di utilizzare il tipo , che consente di ridurre gli errori use-after-free sfruttabili a arresti anomali che non rappresentano una minaccia per la sicurezza, senza un notevole impatto negativo su prestazioni, consumo di memoria e stabilità.
- L'uso di linguaggi progettati per eseguire controlli di sicurezza della memoria in fase di compilazione (eliminerà l'impatto negativo sulle prestazioni inerente a tali controlli durante l'esecuzione del codice, ma comporterà costi aggiuntivi per l'organizzazione dell'interazione del codice in una nuova lingua con il codice in C++).
L'utilizzo di librerie memory-safe è il modo più semplice, ma anche meno efficiente. Riscrivere il codice in Rust è considerato il modo più efficace, ma anche molto costoso.
Fonte: opennet.ru