GitLab corrige deux failles critiques, dont une très simple à exploiter
Simple comme un email
GitLab a corrigé deux failles critiques de sécurité, dont une possédant un score CVSS de 10, le maximum. Elles touchent de nombreuses versions. L'entreprise recommande aux clients de mettre à jour leurs instances aussi rapidement que possible.
Le 15 janvier à 10h48
4 min
Sécurité
Sécurité
GitLab, concurrent open source de GitHub, est une plateforme de DevSecOps, avec suivi des bugs et modifications, proposant des fonctions de type CI/CD (intégration continue, livraison continue) et de wiki. Elle a connu notamment un succès renouvelé quand Microsoft a annoncé le rachat de GitHub.
Le service a reçu en fin de semaine dernière deux correctifs conséquents, à destination de deux failles critiques aux notes de sévérité très élevées : 9,6 et surtout 10 pour la seconde. Une note maximale que peu de failles atteignent. On se souvient par exemple de la vulnérabilité béante chez ownCloud en novembre.
Sévérité maximale et exploitation « triviale »
La faille notée 10, estampillée CVE-2023-7028, réside dans le processus de vérification des courriers électroniques quand une réinitialisation du mot de passe est demandée. Exploitée, elle peut faciliter la prise de contrôle d’un compte en envoyant des emails de réinitialisation à des adresses non vérifiées.
« Dans ces versions, tous les mécanismes d'authentification sont concernés. En outre, les utilisateurs qui ont activé l'authentification à deux facteurs sont vulnérables à la réinitialisation du mot de passe, mais pas à la prise de contrôle du compte, car leur deuxième facteur d'authentification est nécessaire pour se connecter », indique GitLab dans son bulletin. GitLab recommande chaudement d'activer l’authentification à deux facteurs si ce n'est pas déjà fait. Voilà qui rejoint notre dernier édito sur le sujet.
La dangerosité de la faille tient aux conséquences de son exploitation, la possibilité de s’en servir à distance et l’extrême facilité à le faire, l’ANSSI la qualifiant de « triviale » (une requête HTTP POST suffit). GitLab indique ne pas avoir détecté d’exploitation active de cette faille.
Cette dernière concerne de nombreuses versions, pour les éditions Community et Enterprise :
-
- 16.1.x antérieures à la 16.1.6
-
- 16.2.x antérieures à la 16.2.9
-
- 16.3.x antérieures à la 16.3.7
-
- 16.4.x antérieures à la 16.4.5
-
- 16.5.x antérieures à la 16.5.6
-
- 16.6.x antérieures à la 16.6.4
-
- 16.7.x antérieures à la 16.7.2
Tous les comptes affectés par l’une de ces versions ont été avertis par email.
Outre l’application des mises à jour, GitLab recommande de vérifier deux éléments. D’une part, le journal d’activité « gitlab-rails/production_json.log » pour y chercher d’éventuelles traces de requêtes HTTP sur le chemin « /user/password », avec plusieurs adresses. D’autre part, dans le journal « gitlab-rails/audit_json.log », de possibles identifiants correspondant à « PasswordsController#create » avec des « target_details » contenant plusieurs adresses.
D'autres failles corrigées, dont une critique
L’autre faille, nommée CVE-2023-5356, dispose d’un score CVSS de 9,6, la rendant presque aussi critique. Exploitée, elle peut permettre à un attaquant d’abuser des intégrations Slack et Mattermost pour exécuter des commandes (via « / ») en se faisant passer pour un autre utilisateur.
Toutes les versions antérieures aux 16.5.6, 16.6.4 et 16.7.2 sont touchées. Là encore, il est recommandé de mettre à jour les instances concernées aussi rapidement que possible.
À noter que deux correctifs supplémentaires sont proposés. Le premier est pour la faille CVE-2023-4812 (CVSS 7,6), qui peut permettre de contourner l’approbation CODEOWNERS. Le second colmate la brèche CVE-2023-6955 (CVSS 6,6), qui peut permettre la création d’un espace de travail dans un groupe associé avec l’agent utilisateur d’un autre groupe.
GitLab corrige deux failles critiques, dont une très simple à exploiter
-
Sévérité maximale et exploitation « triviale »
-
D’autres failles corrigées, dont une critique
Commentaires (8)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 15/01/2024 à 16h16
Le 15/01/2024 à 16h25
Le 15/01/2024 à 16h42
et je me suis demandé "pourquoi je garde ce service, les potes qui étaient dessus sont finalement allés chez github malgré leurs bonnes intentions ?"
Le 15/01/2024 à 16h45
Sinon en perso c'est clair que la question se pose vraiment, surtout sur des projets opensources.
Le 15/01/2024 à 16h59
Le 15/01/2024 à 17h47
Le 15/01/2024 à 18h51
Ça n'a pas duré longtemps. Serveur patché vendredi matin, les premières tentatives ont eu lieu en milieu d'après-midi et depuis ça n'arrête pas...
Modifié le 15/01/2024 à 22h53
Sur mon site perso c'est fou le nombre de personnes intéressées par des
.env
ou autre dossierswp-admin
.