Une vulnérabilité de Gerrit compromet Google Chromium

Une vulnérabilité critique dans le système de revue de code open source Gerrit, utilisé par Google, a été détectée et nommée « GerriScary » (CVE‑2025‑1568). Cette faille a permis à des utilisateurs enregistrés, sans droits administratifs, d’injecter du code malveillant dans plusieurs projets Google majeurs, compromettant notamment ChromiumOS, Chromium, Dart, Bazel et d’autres.

Contexte et découverte

Découverte par les chercheurs de Tenable Cloud Research (notamment Liv Matan), la vulnérabilité s’est manifestée à travers une mauvaise configuration des permissions dans Gerrit et une condition exploitée par les attaquants. Dénommée « GerriScary », elle a été attribuée au CVE‑2025‑1568.

Gerrit est un outil web de revue de code développé par Google, largement utilisé tant en interne qu’en open-source. Comme tout projet Gerrit, n’importe qui peut s’enregistrer et obtenir des permissions minimales telles que addPatchSet, permettant d’ajouter des révisions de patches aux changements existants.

Nature de la vulnérabilité

Le cœur du problème tient à deux failles :

a. Permissions par défaut trop larges : tout utilisateur enregistré pouvait ajouter une nouvelle version d’un patch pré-approuvé, via addPatchSet.

b. Copy Conditions mal configurées : les étiquettes d’approbation (« labels »), comme **Code‑Review** ou **Commit‑Queue**, étaient copiées automatiquement vers les patch sets suivants sans exiger une nouvelle validation. Cette configuration erronée a empêché une revalidation du nouveau patch, ouvrant la voie à des injections malveillantes.

Exploitation via condition de course

Les chercheurs ont observé que lorsqu’un patch recevait une approbation « Commit‑Queue +2 », un bot Gerrit lançait la fusion automatique après un délai de quelques minutes. Les attaquants pouvaient alors profiter de cette fenêtre pour modifier le patch approuvé en injectant du code malicieux, lequel était fusionné sans revalidation.

Concrètement, le scénario se déroulait en trois étapes :

• Soumission d’un patch innocent accepté par un développeur.
• Dès que l’étiquette **Commit‑Queue +2** est attribuée, le script de reconnaissance la détecte.
• Le script injecte un patch malveillant via addPatchSet avant l’exécution du bot, contournant la nécessité d’une nouvelle approbation.

Le délai entre la pose de l’étiquette et la fusion varie selon les projets : quelques secondes à une minute pour certains, jusqu’à cinq minutes pour ChromiumOS et Dart.

Étendue des projets compromis

Au moins 18 projets Google étaient concernés, parmi lesquels :

ChromiumOS, Chromium, Dart, Bazel, Dawn, BoringSSL, GN, Gerrit, Ceres Solver, Quiche, Android‑KVM, Opensecura, Cue, Linux, Plan9port, Hafnium, Nginx….

Ces projets sont stratégiques : ChromiumOS équipe les Chromebooks, Chromium est au cœur de Chrome, Dart sert la plateforme Flutter et Bazel constitue le moteur de construction. Une compromission aurait pu avoir un impact global massif.

Preuve de concept

Pour valider leur découverte, les chercheurs ont conçu des preuves de concept :

- Injection d’un simple commentaire dans le dépôt ChromiumOS, visible via Code Search.
- Pas de test complet en production par précaution éthique, mais démonstration technique dans plusieurs projets.

Scan automatisé et identification des cibles

Les chercheurs ont déployé un outil de scan capable de détecter les projets vulnérables sans provoquer d’erreurs visibles. En analysant les codes de réponse HTTP (200 ou 209) des requêtes visant à modifier un message de commit, ils pouvaient déterminer si le patch set pouvait être modifié via addPatchSet.

Réponse et remédiation par Google

Google a répondu rapidement après divulgation (octobre 2024) :

• Désactivation de addPatchSet pour les utilisateurs non fiables sur les projets critiques, notamment ChromiumOS.
• Correction des conditions de copie pour obliger une revalidation des labels à chaque patch set.
• Déploiement d’audits sur d’autres projets Gerrit similaires.
• Attribution d’un bug bounty de 5 000 $ pour le signalement.
• Publication du CVE‑2025‑1568 en février 2025.

Gravité technique et notation CVSS

Le NVD attribue une note CVSS 3.1 de 8.8 (« High ») à CVE‑2025‑1568, indiquant un risque important potentiellement aboutissant à une exécution de code à distance ou une interruption des services via la chaîne logistique de développement.

Enseignements et bonnes pratiques

Plusieurs leçons majeures émergent de l’incident :

• Ne jamais accorder l’accès addPatchSet par défaut à des utilisateurs non triés. Restreindre ce droit aux collaborateurs de confiance.
• Activer la revalidation des labels à chaque patch set pour éviter toute continuation implicite d’une approbation antérieure.
• Mettre en place des contrôles temporels entre approbation et fusion ; analyser les délais automatisés pour éviter les attaques par condition de course.
• Auditer systématiquement les configurations Gerrit, notamment Copy Conditions et étiquettes personnalisées comme “Commit‑Queue”.
• Standardiser des pipelines CI/CD avec revalidation cryptographique, signatures de commit et vérifications automatisées (“zero trust”).

Répercussions globales

L’incident souligne que même des géants comme Google restent vulnérables à des failles de configuration dans leurs outils de développement. Il rappelle que la chaîne logistique logicielle est aussi critique que le code final, et que toute faiblesse dans le processus de revue peut exploiter massivement des projets open-source.

En résumé

GerriScary (CVE‑2025‑1568) a révélé que des permissions trop larges et l’absence de revalidation dans Gerrit peuvent conduire à des injections silencieuses de code malveillant dans des projets majeurs. Grâce à la divulgation responsable de Tenable, Google a mis en place des mesures correctives : retrait des droits pour les utilisateurs non fiables et validation stricte des étiquettes. Toutefois, cette affaire reste un signal d’alerte global dans l’écosystème open source et DevOps. Chaque mainteneur doit désormais considérer la sécurité des accès, le temps système et la revalidation comme des axes critiques de protection.

Sources :
Rapport Tenable - GerriScary: Hacking the Supply Chain of Popular Google Products (ChromiumOS, Chromium, Bazel, Dart & More).
Security Week - Gerrit Misconfiguration Exposed Google Projects to Malicious Code Injection.