{"id":82793,"date":"2020-05-25T07:41:55","date_gmt":"2020-05-25T05:41:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/70-problem-s-bezopasnostyu-v-chromium-vyzvany-oshibkami-pri-rabote-s-pamyatyu"},"modified":"2020-05-25T07:41:55","modified_gmt":"2020-05-25T05:41:55","slug":"70-problem-s-bezopasnostyu-v-chromium-vyzvany-oshibkami-pri-rabote-s-pamyatyu","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/novosti-interneta\/70-problem-s-bezopasnostyu-v-chromium-vyzvany-oshibkami-pri-rabote-s-pamyatyu","title":{"rendered":"Il 70% dei problemi di sicurezza in Chromium \u00e8 causato da errori nella gestione della memoria","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Gli sviluppatori del progetto Chromium hanno analizzato<\/a><\/noindex> Sono state identificate 912 vulnerabilit\u00e0 pericolose e critiche nelle versioni stabili di Chrome dal 2015, e si \u00e8 giunti alla conclusione che il 70% di esse \u00e8 stato causato da un utilizzo non sicuro della memoria (errori di gestione dei puntatori nel codice C\/C++). La met\u00e0 di questi problemi (36,1%) \u00e8 dovuta ad accessi al buffer dopo il rilascio della memoria ad esso associata (use-after-free).
\n

\"Il<\/a><\/noindex><\/center><\/p>\n

Nella progettazione di Chromium si \u00e8 inizialmente preveduto<\/a><\/noindex>, che nel codice potevano verificarsi errori, per cui si puntava molto sull'applicazione della sandboxing per limitare le conseguenze delle vulnerabilit\u00e0. Attualmente, le capacit\u00e0 di applicare questa tecnologia hanno raggiunto il loro limite e ulteriori suddivisioni in processi non sono sostenibili in termini di consumo di risorse. <\/p>\n

Per mantenere la sicurezza della base di codice, Google applica anche \"regola del due<\/a><\/noindex>\", secondo cui qualsiasi codice aggiunto deve soddisfare non pi\u00f9 di due condizioni su tre: trattare dati in ingresso non verificati, utilizzare un linguaggio di programmazione non sicuro (C\/C++) e operare con privilegi elevati. Da questa regola deriva che il codice per la gestione di dati esterni deve essere ridotto ai privilegi minimi (isolato) o deve essere scritto in un linguaggio di programmazione sicuro.<\/p>\n

Per migliorare ulteriormente la sicurezza della base di codice, \u00e8 stato avviato un progetto per prevenire la comparsa di errori di gestione della memoria nella base di codice. Vengono evidenziati tre approcci principali: la creazione di librerie C++ con funzioni per una gestione sicura della memoria e l'estensione dell'ambito del garbage collector, l'utilizzo di meccanismi di protezione hardware MTE<\/a><\/noindex> (Memory Tagging Extension) e la scrittura di componenti in linguaggi che garantiscono una gestione sicura della memoria (Java, Kotlin, JavaScript, Rust, Swift).<\/p>\n

Si prevede che il lavoro sar\u00e0 concentrato in due direzioni: <\/p>\n