GitLab faille critique CVSS 10 : patchez maintenant
Une faille GitLab notée 10 sur 10. Le score maximum. Celui qu’on ne voit quasiment jamais dans une carrière de technicien, sauf quand quelqu’un a vraiment fait fort. Autant dire que quand j’ai vu passer le mail d’alerte la semaine dernière, j’ai arrêté mon café en plein milieu. Une faille gitlab de ce calibre, ça ne se contente pas de faire joli dans un bulletin de sécurité : ça permet à n’importe qui, sans même un compte sur l’instance, d’exécuter du code sur ton serveur. Trois CVE critiques en trois semaines sur le même produit. À un moment, il faut arrêter de faire semblant.
La faille GitLab qui transforme une regex en porte d’entrée
Le mécanisme, pour faire simple, passe par le traitement des expressions régulières dans les pipelines CI/CD. Une regex mal construite, côté serveur, peut être exploitée pour faire déborder un buffer ou déclencher une exécution de code non prévue. Le problème, c’est que ce traitement se fait avant l’authentification. Pas besoin de login. Pas besoin de token. Pas besoin d’être invité sur le projet. Tu envoies une requête bien craftée, et le serveur exécute ce que tu lui dis d’exécuter.
Je ne suis pas certain à 100% du chemin d’exploitation exact sans avoir le patch sous les yeux, mais d’après mon expérience en atelier, ce genre de faille sur les runners et le parsing CI/CD finit toujours par se transformer en petit rootkit bien tranquille. Tu ne le vois pas passer. Tu ne le vois pas partir. Et deux semaines plus tard, ton GitLab parle à une IP en Lettonie.
Ce qui me dérange le plus, ce n’est pas la faille en elle-même. C’est le rythme. Trois CVE critiques en vingt et un jours. Ce n’est plus de la malchance, c’est un motif. Une équipe qui sort trois correctifs majeurs en trois semaines sur des composants aussi sensibles, ça raconte quelque chose sur la dette technique accumulée et sur la pression de sortie des features.
Pourquoi cette faille gitlab me fait plus peur que les deux précédentes
Les deux failles précédentes exigeaient au minimum un compte authentifié, avec des privilèges limités mais réels. Celui qui exploitait devait déjà avoir un pied dans la maison. Là, c’est la porte d’entrée grande ouverte sur la rue. N’importe quel script kiddie avec un scanner générique peut tenter sa chance. Et ça, ça change tout.
J’ai un client, une PME de dix-huit personnes dans le BTP, qui fait tourner GitLab CE auto-hébergé sur un vieux serveur dans un placard. Pas de mise à jour depuis huit mois. « Ça marche, on ne touche pas. » Sauf que ça marche pour les devs et pour le stagiaire en alternance, mais aussi pour le premier venu qui connaît la CVE. La semaine dernière, je lui ai envoyé un SMS. Il m’a répondu « c’est quoi GitLab ? ». Voilà. Voilà le niveau de conscience du risque dans certaines boîtes.
Mine de rien, GitLab a longtemps été le « gentil » de la bande, celui qu’on recommandait aux clients méfiants de GitHub parce qu’on pouvait l’héberger soi-même. On vantait la souveraineté, la maîtrise des données, tout ce baratin. Sauf que la souveraineté, ça veut aussi dire être responsable de ses propres correctifs. Et quand tu ne patches pas, tu n’es pas souverain. Tu es juste en retard.
Les versions à installer, et pourquoi il faut le faire aujourd’hui
Les versions corrigées sont disponibles. Les branches concernées sont les suivantes : la 17.4.x, la 17.3.x et la 17.2.x. GitLab recommande de mettre à jour vers les versions les plus récentes de ces branches, à savoir la 17.4.2, la 17.3.5 et la 17.2.9. Les instances plus anciennes, type 16.x, ne sont pas couvertes par ce correctif et doivent être migrées en urgence, ce qui, dans la vraie vie, va poser problème à pas mal de monde.
- 17.4.2 : la cible principale pour les instances récentes.
- 17.3.5 : pour ceux qui sont restés sur la branche 17.3 par prudence.
- 17.2.9 : la version de secours pour les setups plus anciens.
- Migrations 16.x : à planifier immédiatement, pas la semaine prochaine.
Pour être honnête, la mise à jour elle-même n’est pas compliquée. C’est du classique : backup de la base, backup des dépôts, arrêt du service, mise à jour des paquets, redémarrage. Sur une instance de taille moyenne, ça se fait en une heure. Le vrai problème, c’est le après. Parce qu’une faille critique qui exploite un service authentifié, ça veut dire qu’il faut aussi vérifier qu’on n’a pas déjà été compromis avant de patcher. Sinon tu nettoies la porte, mais le cambrioleur est déjà dans le salon.
Ce que je fais concrètement chez mes clients quand une CVE tombe
J’ai une petite routine. Pas parfaite, mais elle m’a évité pas mal de sueurs froides. Dès qu’une faille CVSS 9 ou 10 tombe, je ne cherche pas à comprendre les détails techniques. Je regarde d’abord les logs d’accès des dernières 24 heures. Je cherche des requêtes anormales sur les endpoints CI/CD, des User-Agent bizarres, des pics de 403 en rafale. Ça prend dix minutes et ça te dit si quelqu’un a déjà essayé.
Ensuite, je patch. Toujours. Même si l’instance est en maintenance, même si les devs râlent. Autant dire que quand on parle d’exécution de code à distance non authentifiée, la fenêtre de tir pour un attaquant se compte en heures, pas en jours. Les bots qui scannent les plages d’IP en cherchant les signatures GitLab sont déjà passés. Ils ne lisent pas ton blog préféré pour savoir quand patcher, ils patchent à leur façon.
Et enfin, je documente. Court, factuel, daté. Parce que la prochaine fois qu’une CVE sortira, dans deux semaines probablement, je veux pouvoir comparer et voir si le rythme s’accélère. Mine de rien, un fichier texte avec cinq lignes datées vaut mieux qu’un long rapport que personne ne lira.
Petite digression, mais elle a son importance : j’ai vu un client l’année dernière qui avait patché GitLab mais oublié de patcher le runner auto-hébergé. La faille était corrigée sur le serveur principal, mais les jobs tournaient toujours sur une version vulnérable du runner. On a passé trois heures à chercher pourquoi le scan de vulnérabilité remontait encore une alerte. Autant dire que la mise à jour d’un GitLab, c’est toute la chaîne, pas juste le gros serveur qui brille.
Mon avis tranché sur la gestion des CVE par GitLab
Je vais être direct : je trouve que GitLab communique mal sur ce sujet. Pas sur le contenu des avis, qui sont corrects techniquement. Sur l’urgence. Les bulletins sont publiés avec un ton neutre, presque administratif, comme s’il s’agissait d’une mise à jour de routine. Pour une faille CVSS 10, on devrait avoir un bandeau rouge, un email, un SMS, une notification push, que sais-je encore. Là, on a un article dans un changelog que personne ne lit avant qu’il ne soit trop tard.
Et je vais encore plus loin : le rythme de trois CVE critiques en trois semaines devrait déclencher un audit externe. Pas parce que l’équipe est incompétente, elle ne l’est pas. Mais parce qu’à ce niveau de récurrence, il y a un problème systémique quelque part, dans la revue de code, dans les tests de sécurité, dans la priorisation des correctifs. Mine de rien, un produit qui sert de colonne vertébrale à des milliers d’équipes de dev mérite un peu plus de rigueur sur la sécurité offensive.
Attention, hein, je ne crache pas sur GitLab. J’en installe chez mes clients depuis des années. C’est un excellent outil, la version CE est généreuse, l’auto-hébergement est un vrai argument. Mais l’excellence technique ne dispense pas de l’exigence sécuritaire. Et là, sur ce mois précis, l’exigence n’est pas au rendez-vous.
Ce qui va se passer dans les prochaines semaines, et ce que tu dois faire
Tu vas recevoir d’autres alertes. Probablement une quatrième CVE critique dans les quinze jours, si le rythme se maintient. Ce n’est pas de la prophétie, c’est de la statistique simple. Trois en trois semaines, ce n’est pas un accident, c’est une tendance. Du coup, tu as deux options. Soit tu patches au coup par coup en espérant que ça suffise. Soit tu mets en place une vraie routine de veille et de mise à jour, avec des fenêtres planifiées, des backups testés, et un inventaire clair de tes instances GitLab, runners compris.
La deuxième option est plus chiante à mettre en place. Elle prend du temps. Elle coûte un peu d’argent si tu externalises. Mais elle te fera dormir. Et mine de rien, dormir, quand on gère une infra de dev avec du code client dedans, c’est quand même le minimum syndical.
Si tu ne sais pas par où commencer, commence par vérifier ta version. Une commande, un coup d’œil au dashboard admin, et tu sais si tu es exposé. Si tu es en 17.4.2, 17.3.5 ou 17.2.9, tu peux respirer. Sinon, tu sais ce qu’il te reste à faire ce soir.
Pour être honnête, je ne suis pas certain que cette faille soit déjà exploitée à grande échelle. Les preuves publiques manquent, et GitLab ne communique pas là-dessus. Mais d’après mon expérience, une CVSS 10 sans authentification, ça se fait scanner en quelques heures. Alors ne joue pas au plus malin.
Source : Les news de Korben – GitLab, encore une faille CVSS 10
Source : article original
