2 pièce(s) jointe(s)
Projet Chromium : environ 70 % des bogues de sécurité sont des problèmes liés à la sécurité de la mémoire
Projet Chromium : environ 70 % des bogues de sécurité sont des problèmes liés à la sécurité de la mémoire
les ingénieurs de Google étudient les moyens de corriger ces problèmes à la source
Les ingénieurs de Google travaillant sur le projet Chromium ont récemment déclaré qu’environ 70 % de tous les bogues de sécurité graves dans la base de code Chrome sont des bogues de sécurité de la mémoire. Une précision a également été apportée sur le fait qu’il s’agisse des erreurs avec les pointeurs C / C ++ et que la moitié d’entre eux sont des bogues d'utilisation de la mémoire après libération.
Ce pourcentage est le résultat obtenu après que les ingénieurs de Google aient analysé 912 bogues de sécurité corrigés dans la branche stable de Chrome depuis 2015. Ces bogues, qui précisons-le, avaient une côte de gravité élevée ou critique. En réalité, le problème essentiel serait le fait que le C et le C ++ qui sont les deux langages de programmation prédominants dans la base de code de Chrome, sont des langages qualifiés comme étant non-sûrs. Ils permettent aux programmeurs d'avoir un contrôle total sur la façon dont ils gèrent les pointeurs de mémoire d'une application, mais ne viennent pas avec des restrictions ou des avertissements pour empêcher ou alerter les développeurs lorsqu'ils font des erreurs de gestion de mémoire de base.
Diagramme présentant les causes des bogues liés à la mémoire
Ainsi donc, lorsque les développeurs commettent de telles erreurs, cela crée des failles susceptibles d’être exploitées par les attaquants. Toutefois, il faut rappeler que l’architecture de sécurité de Chromium a toujours été conçue pour supposer que ces bogues existent et le code est mis dans une espèce de zone de quarantaine (sandbox) pour empêcher aux pirates de prendre le contrôle de la machine hôte. Ainsi, pour chaque nouvelle fonctionnalité Chrome écrite par les ingénieurs Google, le code ne devait pas enfreindre plus de 2 des règles suivantes :
- le code gère les entrées non fiables ;
- le code fonctionne sans bac à sable ;
- le code est écrit dans un langage de programmation dangereux (C / C ++) ;
Illustration de la règle de 2 de Google
Jusqu’à présent, les ingénieurs de Google ont toujours utilisé l’approche sandbox dans Chrome et ils ont d’ailleurs récemment déployé une fonctionnalité qui place également les ressources de chaque site dans son propre sandbox. Seulement, ils estiment que cette approche a atteint son potentiel maximum et qu’il est temps d’envisager de nouvelles options qui permettront de résoudre ces problèmes de sécurité.
C’est donc ainsi qu’ils font savoir qu’ils essaient de corriger les classes de bogues plutôt que d’essayer de les contenir par tous les moyens. Cela passe par l’utilisation des langages de programmation plus sûrs (Rust, Swift, JavaScript, Kotlin et Java) partout où cela s'applique, le développement de bibliothèques C ++ personnalisées à utiliser avec la base de code de Chrome et l'utilisation des bibliothèques qui offrent une meilleure protection contre les bogues liés à la mémoire.
Source : Chromium
Et vous ?
:fleche: Qu’en pensez-vous ?
:fleche: Quelles autres options proposeriez-vous aux ingénieurs de Google ?
Voir aussi :
:fleche: La première version stable d'Edge basé sur Chromium est disponible avec le mode Internet Explorer, le support AAD, le streaming 4K et des performances accrues, mais beaucoup reste encore à faire
:fleche: Microsoft va commencer à remplacer son navigateur Edge par la version Chromium cette semaine, seules les entreprises auront la possibilité de se soustraire au processus
:fleche: Microsoft amorce le déploiement de son navigateur Edge basé sur Chromium, tandis que Google recommande aux utilisateurs Edge de passer à Chrome lorsqu'ils visitent ses services Web
