{"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\/news\/70-problem-s-bezopasnostyu-v-chromium-vyzvany-oshibkami-pri-rabote-s-pamyatyu","title":{"rendered":"Il 70% dei problemi di sicurezza in Chromium sono causati da errori nella gestione della memoria","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Gli sviluppatori del progetto Chromium hanno analizzato<\/a><\/noindex> 912 vulnerabilit\u00e0 pericolose e critiche riscontrate nelle versioni stabili di Chrome dal 2015 e hanno concluso che il 70% di esse \u00e8 stato causato da una gestione insicura della memoria (errori nella gestione dei puntatori nel codice C\/C++). La met\u00e0 di questi problemi (36,1%) \u00e8 causata da accessi al buffer dopo il rilascio della memoria associata (use-after-free).
\n

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

Nella progettazione di Chromium \u00e8 stato inizialmente presuposto<\/a><\/noindex>, che nel codice non \u00e8 esclusa l'insorgenza di errori, quindi si \u00e8 puntato molto sull'applicazione della sandboxing per limitare le conseguenze dell'emergere delle vulnerabilit\u00e0. Attualmente, le capacit\u00e0 di applicare questa tecnologia hanno raggiunto il limite delle proprie possibilit\u00e0 e ulteriori divisioni in processi non sono praticabili in termini di consumo di risorse. <\/p>\n

Per mantenere la sicurezza del codice, Google applica anche «regola dei due<\/a><\/noindex>«, in base al quale qualsiasi codice aggiunto deve soddisfare non pi\u00f9 di due condizioni su tre: lavorare con input 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 dei dati esterni deve essere ridotto a privilegi minimi (isolato) oppure deve essere scritto in un linguaggio di programmazione sicuro.<\/p>\n

Per ulteriormente rafforzare la sicurezza della base di codice, \u00e8 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 MTE<\/a><\/noindex> (Memory Tagging Extension) e scrivere componenti in linguaggi che garantiscano una gestione sicura della memoria (Java, Kotlin, JavaScript, Rust, Swift).<\/p>\n

Ci si aspetta che il lavoro si concentri su due direzioni: <\/p>\n