Discussion :

[Jonathan]

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 ?

Qu’en pensez-vous ?
Quelles autres options proposeriez-vous aux ingénieurs de Google ?

Voir aussi :
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
Microsoft va commencer à remplacer son navigateur Edge par la version Chromium cette semaine, seules les entreprises auront la possibilité de se soustraire au processus
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

[Jiji66]

C'est exactement pour ces problématiques que Mozzilla utilise Rust.

[transgohan]

Il suffit d'utiliser les bons outils...
Il existe de nombreux outils d'analyse de code statique qui permettent de remonter une bonne partie de ces problèmes.
Et il existe des outils d'analyse dynamique pour compléter.
S'ils avaient ce genre d'outils, et qu'ils corrigeaient au fil de l'eau avant livraison ils auraient des statistiques beaucoup moins inquiétantes...
C'est pas comme s'ils étaient sur du code embarqué, sur du natif c'est tellement simple !

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.

Ah ouais quand même...
Je trouve que cela fait un peu amateur quand même...
On développe une usine à gaz pour se protéger de bugs qu'on peut corriger nous même...

Ils passent des tests au fait avant livraison ?

[Invité]

Il suffit d'utiliser les bons outils...

Heu, on parle de la base de code du navigateur le plus utilisé au monde et développé principalement par google. Alors ok, ça n'empêche pas les bugs mais si la solution était aussi simple que de lancer un coup de valgrind, je pense qu'ils l'auraient déjà appliquée...

[transgohan]

Il est simple de lancer Valgrind oui. On peut même le faire au sein d'une intégration continue en automatique.
Beaucoup plus ardu de corriger certains défauts qu'il remonte.
Mais en même temps cela fait partie de notre métier... (c'est un peu comme dire qu'on peut livrer un logiciel sans le tester votre dialogue...)
Quand on commence à laisser trainer des erreurs en tout genre le produit fini par exploser à la tête du client si vous m'accepter l'expression.

Et non justement... Je ne pense pas qu'ils aient appliqué des outils d'analyse...
Ou tout du moins trop tard dans le développement... Et ils se sont retrouvés avec tellement d'alertes qu'il aurait fallu dédier une équipe entière à leur correction. (c'est ce qu'on a vécu sur un projet dans mon entreprise... 2 mois à 4 personnes pour corriger plus de 8000 défauts critiques... Et je ne parle pas des warnings et autre qui ont été laissé de côté...)
Et dans ces cas là on laisse trainer... Jusqu'à ce que cela soit trop gênant ou qu'on ai le financement.

Mon hypothèse vient de là, ils sont peut être très compétent, mais n'ont pas déployé les bons outils au bon moment.
Puis se sont enlisés dans le nombre de défauts.

Enfin bon... Tout cela pour dire que passer à un autre langage à cause de cela...
C'est faire preuve d'une fausse expertise. Si les développeurs appliquaient les bonnes règles dès le début on ne se poserai pas la question.
Oui d'autres langages permettent une gestion plus sécuritaire de la mémoire et économise du travail au développeur, mais non migrer vers ces langages parce qu'on code mal / qu'on n'utilise pas ou trop peu les outils d'analyse n'est pas une solution pour améliorer la qualité de ses produits...

[marsupial]

D'autant que la sécurité reste délaissée car rébarbative par nombre de développeurs. Il s'agit pour les décideurs d'allouer du temps, donc de l'argent, pour faire du code propre. Mais en ces temps de surveillance généralisée, je pense qu'il s'agit d'un bon point à travailler.

[Invité]

...
Mon hypothèse vient de là, ils sont peut être très compétent, mais n'ont pas déployé les bons outils au bon moment.
Puis se sont enlisés dans le nombre de défauts.
...
Enfin bon... Tout cela pour dire que passer à un autre langage à cause de cela...
C'est faire preuve d'une fausse expertise. Si les développeurs appliquaient les bonnes règles dès le début on ne se poserai pas la question.
Oui d'autres langages permettent une gestion plus sécuritaire de la mémoire et économise du travail au développeur, mais non migrer vers ces langages parce qu'on code mal / qu'on n'utilise pas ou trop peu les outils d'analyse n'est pas une solution pour améliorer la qualité de ses produits...

Et donc à partir d'un camembert sur les types de bugs, tu arrives à déterminer leur workflow, les outils utilisés et les solutions à mettre en oeuvre ?

Sérieusement, il faut arrêter de se croire dans les années 90. Les navigateurs modernes sont aussi complexes que des OS.
D'ailleurs, il n'en reste plus qu'une poignée, même Microsoft a jeté l'éponge. Un navigateur ce n'est plus un client http avec un rendu html basique, c'est aussi un compilateur JS, un système d'extensions, une gestion de droit d'accès aux périphériques, des technos genre webgl, wasm, webrtc, etc, etc. Coder tout ça est légèrement compliqué et demande beaucoup de précautions : d'ailleurs Chromium implémente ses propres sandboxing et garbage collector, et Firefox implémente carrément son langage. Sans compter que les projets sont open-source et acceptent des contributions exterieurs.
Donc non ce n'est pas juste utiliser valgrind dès le début et avoir un peu d'hygiène de dev, et le fait qu'ils se posent des questions pour améliorer leur process est plutôt sain, je trouve.

[transgohan]

Et donc à partir d'un camembert sur les types de bugs, tu arrives à déterminer leur workflow, les outils utilisés et les solutions à mettre en oeuvre ?

Sérieusement, il faut arrêter de se croire dans les années 90. Les navigateurs modernes sont aussi complexes que des OS.

Faut peut être pas abuser tout de même...
Et je pourrai m'étaler si j'étais de nature féroce... Je travaille sur des systèmes qui sont bien plus complexes qu'un navigateur, bien plus contraint en ressources et en temps.
Je vais finir par croire que vous avez des actions chez eux et que vous avez peur que mes réflexions fassent chuter leur cours...

On parle ici d'un assemblage / intégration de différents modules, gérés par différentes équipes.
Chaque équipe se doit d'avoir son protocole de test.
Ici malheureusement on cite les intégrateurs dans leur plus large terme via cet article.
J'ose espérer que personne n'aurai imaginé qu'un navigateur est l'oeuvre d'une seule et même équipe...

et le fait qu'ils se posent des questions pour améliorer leur process est plutôt sain, je trouve

Là je suis en tout point d'accord avec vous.

[Uther]

Il suffit d'utiliser les bons outils...
Il existe de nombreux outils d'analyse de code statique qui permettent de remonter une bonne partie de ces problèmes.
Et il existe des outils d'analyse dynamique pour compléter.

Sauf que les outils d'analyse statique et dynamique ça fait un moment qu'ils les utilisent, malheureusement ça ne fait pas tout. Avec un langage comme le C++, on n'est pas capable de garantir statiquement l'absence de problèmes mémoire et l'analyse dynamique ne détecte pas forcément les corners case qui auraient échappés aux tests.
Alors c'est clairement très important de le faire et ils le font, mais sur des base de code si vastes et qui évoluent autant que les navigateurs il y a forcément des trous.

S'ils avaient ce genre d'outils, et qu'ils corrigeaient au fil de l'eau avant livraison ils auraient des statistiques beaucoup moins inquiétantes...
C'est pas comme s'ils étaient sur du code embarqué, sur du natif c'est tellement simple !

Où peut-être que c'est parce qu'ils ont une vrai contrôle qualité du produit et qu'ils sont surveillés par des centaines d'expert sécurité, qu'ils ont de telles statistiques. Après tout on ne trouve pas les problèmes quand on ne les cherche pas.

Le soucis de l'analyse dynamique c'est que par essence ça ne capture pas tout. Les expert ou les développeurs eux-mêmes, détectent souvent de nouveaux problème en changeant les configurations des outils et des fuzzers, pour tomber sur des cas qui échappaient aux test auparavant ...

Le code embarqué est difficilement comparable. Il est généralement bien plus simple dans ses approches qu'un navigateur (pas de langages ingérées, JIT, ...) même s'il fait des choses niveau matériel. Enfin il est rarement aussi contrôlé dans la durée que celui d'un navigateur.

[transgohan]

les corners case qui auraient échappés aux tests.

J'en comprends que les tests ne couvrent pas 100% du code ? Je me trompe d'interprétation ?

Après effectivement cela dépend du type de test, le fuzzing apporte une sacrée plus-value, mais au détriment du temps d'exécution généralement.
Et on peut difficilement dire qu'on va faire tourner des tests pendant 3 semaines avant de livrer...

[Thomasa21]

les solutions sont connues et il leur suffit d'utiliser les bons outils. Microsoft rencontre les mêmes problèmes qu'eux pourtant tous savent ce qu'il faut faire.

[archqt]

<Troll> Et les smarts pointer alors les gars hein C++11 Oh </Troll>

[Uther]

J'en comprends que les tests ne couvrent pas 100% du code ? Je me trompe d'interprétation ?.

Même si les tests couvrent 100% de la surface du code, ça ne veut pas dire qu'ils déclenchent tous les cas d'erreur possibles

[Steinvikel]

Petite parenthèse, je comparais parfois les vulnérabilité des systèmes d'exploitation, plateforme, outils...
- https://www.cvedetails.com/product/1...vendor_id=1224
- https://www.cvedetails.com/product/3...?vendor_id=452

En comparant les graphes de ces 2 liens, on s’aperçoit rapidement que les vulnérabilités concernent les mêmes faiblesses (code exécutable, dénie de service, overflow... et corruption mémoire).
Les graphes (sur 20 ans) permettent de projeter une tendance par vulnérabilité.

L'explication de " j'ai pas répondu de manière adapté au bon moment, maintenant je n'ai plus la capacité temps/argent pour résoudre le problème à la source" est une explication qui vaut dans beaucoup de milieu pas uniquement le développement info'... personnellement, je la trouve très crédible dans ce contexte.

Ce que je retient surtout, c'est que la solution retenu est :
1) changer de langage, pour un qui soit moins permissif (comprendre environnement de production plus automatisé ...sur la vérification notemment)
2) changer pour des bibliothèques personnalisés ou plus adaptés ...?? parce qu'elles n'ont pas été vérifiés ou adaptés si nécessaire ? =/