GitLab corrige deux failles critiques, dont une très simple à exploiter

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.

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.

• ownCloud : faille béante dans les déploiements conteneurisés utilisant graphapi

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.

• • [Édito] Mots de passe, double authentification : grrrrr… il est temps d’agir !

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.