Gli sviluppatori del progetto Chromium 912 vulnerabilità pericolose e critiche riscontrate nelle versioni stabili di Chrome dal 2015 e hanno concluso che il 70% di esse è stato causato da una gestione insicura della memoria (errori nella gestione dei puntatori nel codice C/C++). La metà di questi problemi (36,1%) è causata da accessi al buffer dopo il rilascio della memoria associata (use-after-free).
Nella progettazione di Chromium è stato inizialmente , che nel codice non è esclusa l'insorgenza di errori, quindi si è puntato molto sull'applicazione della sandboxing per limitare le conseguenze dell'emergere delle vulnerabilità. Attualmente, le capacità di applicare questa tecnologia hanno raggiunto il limite delle proprie possibilità e ulteriori divisioni in processi non sono praticabili in termini di consumo di risorse.
Per mantenere la sicurezza della base di codice, Google applica anche la ““, secondo cui il codice aggiunto deve soddisfare non più di due condizioni su tre: gestione di input non validati, utilizzo di un linguaggio di programmazione insicuro (C/C++) e esecuzione con privilegi elevati. Da questa regola deriva che il codice per la gestione di dati esterni deve essere ridotto a privilegi minimi (isolato) o essere scritto in un linguaggio di programmazione sicuro.
Per ulteriormente rafforzare la sicurezza della base di codice, è stato avviato un progetto per prevenire l'emergere di errori di memoria nel codice. Si individuano tre approcci principali: creare librerie C++ con funzioni per una gestione sicura della memoria ed estendere l'ambito del garbage collector, applicare meccanismi di protezione hardware (Memory Tagging Extension) e scrivere componenti in linguaggi che garantiscano una gestione sicura della memoria (Java, Kotlin, JavaScript, Rust, Swift).
Ci si aspetta che il lavoro si concentri su due direzioni:
- Una significativa modifica del processo di sviluppo in C++, senza escludere un impatto negativo sulle prestazioni (controlli aggiuntivi sui limiti e garbage collection). Invece di puntatori raw, si propone di utilizzare nel codice il tipo , consentendo di ridurre gli errori di tipo use-after-free a crash privi di rischi per la sicurezza, senza un impatto negativo significativo su prestazioni, consumo di memoria e stabilità.
- L'uso di linguaggi progettati per effettuare controlli di sicurezza in fase di compilazione (permette di escludere l'impatto negativo sulle prestazioni tipico di tali controlli in fase di esecuzione del codice, ma comporterà costi aggiuntivi per l'organizzazione dell'interazione tra il codice nel nuovo linguaggio e il codice in C++).
L'uso di librerie per l'uso sicuro della memoria è il modo più semplice, ma anche meno efficace. Riscrivere il codice in Rust è considerato il percorso più efficace, ma anche molto costoso.
Fonte: opennet.ru
