{"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\/fr\/blog\/news\/70-problem-s-bezopasnostyu-v-chromium-vyzvany-oshibkami-pri-rabote-s-pamyatyu","title":{"rendered":"70 % des probl\u00e8mes de s\u00e9curit\u00e9 dans Chromium sont caus\u00e9s par des erreurs de gestion de la m\u00e9moire","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

D\u00e9veloppeurs du projet Chromium ont analys\u00e9<\/a><\/noindex> 912 vuln\u00e9rabilit\u00e9s dangereuses et critiques d\u00e9tect\u00e9es dans les versions stables de Chrome depuis 2015, et il a \u00e9t\u00e9 conclu que 70 % d'entre elles \u00e9taient dues \u00e0 une mauvaise gestion de la m\u00e9moire (erreurs de gestion des pointeurs dans le code C\/C++). La moiti\u00e9 de ces probl\u00e8mes (36,1 %) sont caus\u00e9s par des acc\u00e8s au tampon apr\u00e8s la lib\u00e9ration de la m\u00e9moire associ\u00e9e (use-after-free).
\n

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

Lors de la conception de Chromium, il a \u00e9t\u00e9 pr\u00e9vu<\/a><\/noindex>, que des erreurs pourraient appara\u00eetre dans le code, c'est pourquoi une grande importance a \u00e9t\u00e9 accord\u00e9e \u00e0 l'application de l'isolation sandbox pour limiter les cons\u00e9quences de l'apparition de vuln\u00e9rabilit\u00e9s. Actuellement, les capacit\u00e9s d'application de cette technologie ont atteint leur limite et une fragmentation suppl\u00e9mentaire des processus n'est pas justifi\u00e9e du point de vue de la consommation des ressources. <\/p>\n

Pour maintenir la s\u00e9curit\u00e9 de la base de code, Google applique \u00e9galement \u00abr\u00e8gle des deux<\/a><\/noindex>\u00bb, selon lequel tout code ajout\u00e9 ne doit pas r\u00e9pondre \u00e0 plus de deux des trois conditions suivantes : travail avec des entr\u00e9es non v\u00e9rifi\u00e9es, utilisation d'un langage de programmation non s\u00e9curis\u00e9 (C\/C++) et ex\u00e9cution avec des privil\u00e8ges \u00e9lev\u00e9s. De cette r\u00e8gle, il en d\u00e9coule que le code pour le traitement des donn\u00e9es externes doit soit \u00eatre r\u00e9duit \u00e0 des privil\u00e8ges minimaux (isol\u00e9), soit \u00eatre \u00e9crit dans un langage de programmation s\u00e9curis\u00e9.<\/p>\n

Pour renforcer davantage la s\u00e9curit\u00e9 de la base de code, un projet a \u00e9t\u00e9 lanc\u00e9 pour pr\u00e9venir l'apparition d'erreurs de gestion de la m\u00e9moire dans la base de code. Trois approches principales sont mises en avant : cr\u00e9ation de biblioth\u00e8ques C++ avec des fonctions pour une gestion s\u00e9curis\u00e9e de la m\u00e9moire et \u00e9largissement du champ d'application du ramasse-miettes, application de m\u00e9canismes mat\u00e9riels de protection MTE<\/a><\/noindex> (Memory Tagging Extension) et r\u00e9daction de composants dans des langages garantissant une gestion s\u00e9curis\u00e9e de la m\u00e9moire (Java, Kotlin, JavaScript, Rust, Swift).<\/p>\n

Il est attendu que le travail se concentre sur deux directions : <\/p>\n